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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
