[ http://issues.apache.org/jira/browse/DERBY-2133?page=comments#action_12454760 ] Daniel John Debrunner commented on DERBY-2133: ----------------------------------------------
Doh, looked at the wrong section for J2ME/CDC/foundation, MessageDigest is supported so a single approach of always using an MD5 checksum is probably the best. > Detect tampering of installed jar files in an encrypted database > ---------------------------------------------------------------- > > Key: DERBY-2133 > URL: http://issues.apache.org/jira/browse/DERBY-2133 > Project: Derby > Issue Type: Improvement > Components: Security > Reporter: Daniel John Debrunner > > Since the jar files (from sqlj.install_jar) are stored unencrypted in an > encrypted database a secuirty hole exists where the jar can be replaced by > malicious code. > One way to detect this would be to store an MD5 checksum of the jar's > contents in the SYSFILES table (as a new column) and to match this checksum > with the jar file when opening it. This only makes sense for encrypted > databases, as if a cracker can hack the jar file in an unencrypted database > they can also fix up the checksum. Also adding this checksum on a unencrypted > database would require some alternate scheme for J2ME/CDC/Foundation which (I > think) does not support MD5 checksums. > th eother option of encrypting the jar seems less appealing as it will > increase the complexity of loading classes and move away from using the > standard URLClassLoader. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
