Internal security of Rev?

[John Tregea]

Hi Dar,

Thanks for your extensive reply. The point you raised about info leaks 
through memory was one of my two concerns, the other was what could be 
seen by 'peaking' into the built application. I guess I can overwrite 
the memory variables I use by setting them to empty at the end of each 
handler. I planned to do that when the user logs out anyway. I also was 
going to store the variables in custom properties (in encrypted form) 
during the session and set them to empty at the end of a session.

Really there is just two things that have to be stored in the Rev side 
of the solution. That is the login user name and password for the 
postgreSQL database. Once the connection is made through that default 
account, there is a two, three or four factor validation process from 
within POstgreSQL.

I realised that I may be able to use the location of certain objects 
within the front end to build the key. The objects never move in 
relation to each other and the resulting string of numbers would be a 
perfectly hidden string.

maybe something like

repeat with x = 1 to the number of btns 
    put char 1 of the short name of btn x & item 1 of the loc of btn x 
after tTheKey
    if length(tTheKey) > 16 then exit repeat
end repeat
put char 1 to 16 of tTheKey into tTheKey

-- the key would end up something like b234t256h678f67u (a 128 bit key)

?

I would have to be careful that the stack window never has a new button 
inserted at a low layer in subsequent versions, or the clients would 
lose there data decrypt capability :-)

Any thoughts?

John

Dar Scott wrote:
>
> On Jul 12, 2006, at 2:27 AM, John Tregea wrote:
>
>> Yes my original question was about protecting classified information 
>> within a database where the front end may end up being Rev based.
>
> You are mixing two levels.
>
> If the information is encrypted and decrypted with a "hardwired" key, 
> it is virtually part of the application.  It is subject to the 
> limitations discussed.
>
> However, if it is encrypted using a user supplied key, then it stands 
> alone as encrypted information.  The user supplied key might be a 
> certificate, a passphrase, or a passphrase to get to a certificate.
>
> You can mix the user key with "hardwired" key to slow down decrypting 
> without the user supplied key.
>
> So, you need a user-supplied key.
>
>
>> But the structure of the stand alone rev application is my remaining 
>> concern. (unless you all think of some stuff I haven't thought of.)
>>
>> The classified information would specifically be for supply chain 
>> risk assessments under ISO 28000 and 28001. We hope to use Rev to 
>> build a front end to a proprietary database structure, but have to 
>> know we can certify the resulting application under ISO 17799 
>> (Information Security Management) before clients would be prepared to 
>> use the product/service.
>
> Revolution uses good cryptographic functions.  It uses a library that 
> has undergone review and has a controlled build distribution process.
>
> However, 1) you don't know what kinds of sneaking things folks at 
> RunRev have put into their code.  I don't think they have done 
> anything sneaky, I mean you are not able to demonstrate that they have 
> not, without going to extra effort.  Also, 2) I would not be surprised 
> if there are RAM info leaks through Revolution's memory management.  
> That is, unused memory might be returned to the system without being 
> written over.  Rev does a lot of copying.  (I do some things to 
> mitigate this, but I have no idea if they really do any good.)  If 
> those are not a concern for ISO 17799, I think you are OK.
>
> Rev encryption is based on openSSL libraries and you need to make sure 
> you have a good copy of a reviewed version.  Don't ship with what you 
> get from RunRev for Windows; download a new copy and check the digest.
>
> SSL is normally app to app, so you should be OK there, too.  However, 
> at this time, you cannot supply a cert from the client side with Rev.  
> (Unless something happened when I was asleep.)  Hmmm.  There should be 
> an enhancement request for this.
>
> Dar Scott
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>