EAS309 Cryptography and EAServer

1. EAS309 Cryptography and EAServer Jason WeissSenior Architect, Sybase OEM Engineeringweissj@sybase.comAugust, 2003

2. Overview • Cryptography is something every distributed developer needs to have a basic comprehension of in today’s networked world • This session will include a cryptography definitions and real-world code examples using the Java Cryptography Architecture/Java Cryptography Extensions • A demonstration of PowerBuilder integration will also be given. To date, PowerBuilder has never provided an easily accessible cryptology platform.

3. Background • Presently a Senior Architect for Sybase OEM Engineering working with content capture and embeddable portal engines • Prior to current role at Sybase, served as Chief Architect at Personified Technologies, LLC working on the company’s flagship DRM product. • Previously held active-duty over seas Naval Intelligence (CTT) billet ( • Worked with the NSA on cryptosystem designs • Authored the leading EAServer book, “Taming Jaguar” • Author of the soon to be released “Java Cryptography Extensions: Programmer-to-Programmer” book from Morgan-Kaufmann Publishers

4. Topics • JCA Provider Overview: Preparing EAServer • Symmetric Ciphers • Asymmetric Ciphers • Hashing, Message Digests, MACs and Digital Signatures • Key Stores, Certificates

5. JCA Overview • Java Cryptography Architecture • Foundation for Java’s security platform • Built around the java.security package • Design Goal: Implementation Independent and Interoperable • Design Goal: Algorithm Independent and Extensible • Configuration stored in $JAVA_HOME/jre/lib/security/java.security • Implementation Independence • Achieved via a Provider-based architecture • Request just an algorithm or request an algorithm from a specific provider • Simple, clean, intuitive APIs buffer developer from underlying details • Algorithm Independence • Achieved via Engine based architecture • Lookups are factory method based • Implementation Interoperability • Key generated from Provider A is fed to a Cipher from Provider B

6. JCE Overview • Java Cryptography Extensions • Builds upon the architecture of the JCA • Introduces more cryptographic operations, including encryption capabilities • “SunJCE” Provider has limited algorithms. Should download a 3rd party provider that includes more powerful, up-to-date algorithms • Bouncy Castle and Cryptix are two leading JCE Providers • http://www.bouncycastle.org • http://www.cryptix.org • For our demonstration here today, we’ll be using the Bouncy Castle Provider

7. Deploying the BC Provider to EAServer • Providers can be loaded dynamically or statically • My experiences with EAServer have shown dynamic provider registration problematic due to classloader architecture • MUST pay attention to what version of the JVM you are running in your server and what directory it is being pulled from • $JAGUAR\bin\setenv.bat • set SYBASE_SHARED=d:\Program Files\Sybase\Shared • set JAGUAR_JDK12=not_installed • set JAGUAR_JDK13=%SYBASE_SHARED%\jdk1.3.1_06 • set JAGUAR_JDK14=%SYBASE_SHARED%\jdk1.4.1_01 • Access the appropriate JDK’s ./jre/lib/security/java.security file with your favorite text editor

8. Deploying the BC Provider to EAServer (con’t) • Insert the BC provider class into the list, e.g. position #2 • security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider • There is no need to place into position 1 • The “Sun” JCA provider doesn’t offer any Cipher algorithms that would compete with the BC implementations; thus the BC ciphers will be found first • It is a known bug that if you dynamically try to register a provider into position #1 you will crash the JVM. The security architecture attempts to validate the signature of the .jar file, but since the SUN provider is no longer #1, the new provider is, endless loop results in stack overflow and ultimate JVM crash. • Deploy the BC .jar into ./jre/lib/ext folder • Should see the “SunJCE” provider already there! • Restart EAServer • Tweaking the installation

9. Verification of Installation • The sample EJB includes a method that will verify the successful deployment of the Bouncy Castle provider • dumpBCProviderList(String engine) • The predominate engine to pass in is Cipher. This should result in a large listing of available ciphers:

10. Topics • JCA Provider Overview: Preparing EAServer • Symmetric Ciphers • Asymmetric Ciphers • Hashing, Message Digests, MACs and Digital Signatures • Key Stores, Certificates

11. Symmetric Ciphers • Use a single key • Same key used in encryption and decryption operation • Ranges in size from 56-bit to 256-bit. Target a 128-bit or 256-bit key • Useful for encrypting large volumes of data • Block Cipher • A pre-determined amount of data is encrypted at once • Cipher engine waits for the block to fill; bad for real-time communications • Stream Cipher • Encryption happens as each byte (and often bit) comes in • Great for real-time network communications • Arguably, a stream cipher could be considered a block cipher where the block size is one byte!

12. Padding Schemes • Not always possible to create a message that is exactly a multiple of the cipher’s block • Padding simply fills out the rest of the block with meaningless data • Often uses a digit to represent the number of places padded, e.g. 333, 4444, 55555, etc. • Public Key Cryptography Standard #5 (PKCS#5) Padding • Common padding scheme used in symmetric ciphers • Optimal Asymmetric Encryption Padding (OAEP) • Common padding scheme used in asymmetric ciphers

13. Feedback Modes • Goal is to hide patterns in text • Imagine an email, constant with From:, To:, Subject: and other headers • If we didn’t apply a feedback mode to hide this information, over time an attacker could attempt to assemble a library (especially if the same key was used over and over) and begin to identify patterns in the ciphertext • NOT more important as the Cipher algorithm • The Cipher is still more important • Feedback Modes algorithms should be relatively simple; all they need to do is hide text patterns, not encrypt them • Electronic Cookbook Mode (ECB) • No tie from one block to another; e.g. database records could be decrypted on a per record basis, not whole table • An attacker could introduce blocks from previously intercepted messages, thus scrambling the real message and causing chaos! • Cipher Block Chaining • Each cipher block is dependent upon the previous block to successfully decrypt it. The use of an Initialization Vector (IV) primes the process. The IV doesn’t have to be protected; can be sent in the clear • Recommended feedback mode for any encryption data that might be transmitted over a wire

14. Symmetric Cipher Areas of Concern • Key Management • Ideal when the key doesn’t need to be distributed • Non-Repudiation • No way to “prove” who sent the message • Example: Alice and Bob placing orders • Data Integrity • Developers must understand the structure of the resulting ciphertext • Knowledge of ciphertext weaknessess will help avoid compromise • Example: ECB and replay attack

15. Symmetric Cipher Algorithms • DES • 56-bit key • Old, growing more and more outdated each hour • Unless linking to legacy code, avoid using • Triple-DES • a.k.a. DES-EDE for Encrypt – Decrypt – Encrypt • 3x as slow as DES • Attempts to address the small key size • Should avoid using, not really advantageous • AES • a.k.a. Rijndael • Chosen by the NIST via a competition as the replacement of DES • 128-bit or larger key • Others • There are others out there. Be informed and ensure they’ve been scrutinized!

16. com.sybase.pbcrypt.CryptOps • Stand-alone Java utility class that exposes a number of cryptographic methods • EJB Wrapper- PBCrypto/CryptOps • Can be accessed via EJB and invoked from PowerBuilder • Brings advanced cryptography to PB clients and PB NVO components • All method arguments and return data values Base64 encoded where applicable • Can be incorporated as-is into your Java programs • Probably would want to remove the automatic Base64 encoding first • Can be accessed via EJB into your programs • Symmetric Cipher Code Examples: • String generateSecretKey(String algorithm) • StringencryptPlainText(Stringalgorithm,StringsecretKey,StringplainText)

17. Topics • JCA Provider Overview: Preparing EAServer • Symmetric Ciphers • Asymmetric Ciphers • Hashing, Message Digests, MACs and Digital Signatures • Key Stores, Certificates

18. Asymmetric Ciphers • Use two keys • Public- sharable with the world at large • Private- protected at all costs • Keys range from 512-bits to 2048-bits • One key cannot accomplish a round-trip encrypt-decrypt operation by itself • If encrypted by the public key, only the private key can decrypt • If encrypted by the private key, only the public key can decrypt • Primary purpose is for generating a digital signature, some algorithms also support encryption • RSA supports both digital signature and encryption

19. Revisiting Symmetric Cipher Areas of Concern • Key Management • Asymmetric cipher has 2 keys, so key management is double-important • Non-Repudiation • Asymmetric key properties inherently address the non-repudiation issue • Example: Alice and Bob placing orders, part 2 • Data Integrity • Asymmetric ciphers often rely on the same feedback and padding modes used by symmetric ciphers. • Knowledge of cleartext structure is still important

20. My, What a Large Key You Have! • Why are asymmetric keys so large? • Inherent mathematical relationship between the two keys • Key generation involves VERY large prime numbers and modulus operations • n=pq where p and q each contain around 308-digits! • The private key represents 4 different numbers • The public key represents 2 additional different numbers • A “private key” is really 4 different numbers and thus very large • Why isn’t RSA encryption readily supported on PDAs/Cell Phones? • Most PDA’s are prepared to perform exponential operations on 308-digit primes!

21. Asymmetric Encryption • In RSA, amount of plaintext that can be encrypted is restricted due to the mathematical properties of the keys • Solution: Combine Asymmetric and Symmetric Ciphers • Alice generates a symmetric secret key • Alice encrypts large plaintext message using symmetric algorithm (e.g. AES) • Alice encrypt the symmetric secret key using Bob’s public key • Alice sends Bob an email with 2 attachments: ciphertext and encrypted key. In the message body she tells Bob she used an AES symmetric cipher • Even if Eve intercepted Bob’s public key, she doesn’t have enough information to generate Bob’s private key and thus can’t decrypt Alice’s secret key

22. com.sybase.pbcrypt.CryptOps • Asymmetric Cipher Code Examples: • String generateSecretKey(String algorithm) • StringencryptPlainText(Stringalgorithm,StringsecretKey,StringplainText) • String[] createRSAKeyPair() • String encryptSecretKey(String secretKeyData, String publicKey)

23. Topics • JCA Provider Overview: Preparing EAServer • Symmetric Ciphers • Asymmetric Ciphers • Hashing, Message Digests, MACs and Digital Signatures • Key Stores, Certificates

24. Hashing Defined • Why java.util.Hashtable and Object.hashCode() are unsuitable for cryptographic operations • e.g. Employee Bean’s equals() method • Cryptographic uses require a fixed-length hash • Cryptographic uses must be collision-free • 1-bit change should result in radically different hash value • Bruce Schneier anology: • A one-way hash is similar to smashing a plate. Anyone can smash a plate into a bazillion pieces, however, taking all those pieces and re-building the plate is unrealistic • The strength of a one-way hash lies in the hash function itself • Function is not considered secret • Hash value is not considered secret • Message Digest and One-Way Hash are interchangeable terms

25. Available Message Digests • MD5 • 128-bit hash value • Papers are published which describe weakness in algorithm that could lead to a collision • No known exploit based on this information • SHA-1 • 160-bit hash value • Backed by NSA/NIST • Based on similar algorithm to the MD5 hash • NIST recently published SHA-256, SHA-384, and SHA-512. • Don’t use the SHA-384- has the same computational overhead as SHA-512, so you might as well grab the extra bits!

26. com.sybase.pbcrypt.CryptOps • Message Digest Code Examples • String getMessageDigest(String algorithm, String msg)

27. Message Digest Shortcomings • Susceptible to a “Man in the Middle” attack • Eve intercepts the document and the hash value • Eve modifies the document, generates a new hash value • Eve then forwards on the modified document to Bob • Bob verifies everything checks out and thinks the document is authentic!

28. Message Authentication Codes • Combines a message digest with a secret key • If you don’t know the secret key, you can’t generate a new hash value that would match • Conceptually, by publishing the secret key, the MAC is effectively turned into a vanilla message digest

29. com.sybase.pbcrypt.CryptOps • MAC Code Examples • String getMAC(String algorithm, String secret,String msg)

30. MAC Shortcomings • “Replay Attack” • Eve could still intercept the message and rebroadcast to Bob months later, introducing confusion • Could overcome this by incorporating a timestamp into each message • Horton Principle • Authenticate what is being meant not what is being said. Ensure the MAC covers the meaning of the message and not just the raw data.

31. Digital Signatures • Requires asymmetric cryptography and the properties of public/private key pairs • All signatures are done using the private key • All verifications are done using the public key • Surprising to some, the document remains untouched and the digital signature is a separate document sent along with the original • May need to include the public key for verification if it hasn’t been previously distributed

32. Digital Signature Process • Alice generates a PO for Bob’s company to process • Alice generates a message digest of the document using SHA-1 • Using her private key, Alice encrypts the digest value and sends the PO, the encrypted digest value, and clear text instruction on which digest algorithm she used to Bob • Bob receives the PO and runs it through a SHA-1 function and computes the 160-bit key • Using Alice’s public key, Bob decrypts the digest value Alice sent along with the PO and compares his value with her value • If they match • The document hasn’t been tampered with • Only Alice’s private key could have been used to “sign” the digest value

33. Digital Signature Choices • RSA • Invented in the late 1970’s • Considered the de facto standard • Has the unique ability to support digital signatures and encryption • Slow to sign, Fast to verify • DSA • Pushed by the government in the early 1990’s • Only suitable for digital signatures, not encryption • Fast to sign, Slow to verify

34. com.sybase.pbcrypt.CryptOps • Digital Signature Code Examples • String[] createRSAKeyPair() • String signDocument(String privateKey, String msg) • boolean verifySignature(String publicKey, String msg, String signatureValue)

35. Topics • JCA Provider Overview: Preparing EAServer • Symmetric Ciphers • Asymmetric Ciphers • Hashing, Message Digests, MACs and Digital Signatures • Key Stores, Certificates

36. The Need for Key Management • Mathematics can’t solve the key management issue • People are in the custody chain, and people are neither perfect nor machines • Cryptography can be a double-edge sword • If you encrypt a message using a symmetric cipher and you forgot the key, the same encryption that was supposed to keep others out is now keeping you out! • JCA uses a Key Store to hold symmetric keys, asymmetric key pairs, and digital certificates • NOTE: The default key store “JKS” doesn’t work correctly with symmetric keys, but other providers like “BKS” do. If you need to manage symmetric keys, be sure to use a 3rd party provider’s key store format

37. PowerBuilder Note • Presently, the sample code is exposed to PB via an EJB • EJB specification doesn’t permit file I/O operations from inside of an EJB • Key Store access is via a FileInputStream and storage is via FileOutputStream • Can’t access a key store from inside of an EJB! • Any motivated individual could leverage the new PB9 PBNI interface to access the key store via JNI calls

38. Digital Certificates • By itself, a public key is just a public key • No notion of identity • No notion of trust or accountability • Combine a public key with a series of name-value fields and you have a Digital Certificate • Apply a trusted 3rd party’s digital signature to a Digital Certificate and you have a Trusted Certificate • Who do you trust? Thawte? VeriSign? • PKI Utopia would require one and only one Certificate Authority– the trusted 3rd party signing digital certificates • Would you trust the NSA? Microsoft? Anyone with such power? • The answer is no, and thus PKI will never reach its true vision of one person, one certificate, one trusted CA.

39. Digital Certificate Generation • Use keytool utility • keytool -genkey -alias twave -keyalg RSA -keystore /twave.keystore • keytool -certreq -alias twave –file /certreq.csr • CA will go through the authentication process • Typically will provide your signed digital certificate via Base64 Encoding of DER Encoding • You typically distribute your signed digital certificate; no real compelling reason to store in key store • When others send you signed digital certificates, you can import as a “trusted” certificate into your key store • Trust is implied– no real-time authentication checks done by JVM!

40. Certificate Revocation List • For whatever reason, a CA may need to revoke a signed digital certificate prior to its natural expiration date • Each CA must maintain a list known as the CRL with this data • At present, YOU are responsible for checking with the CA for updated CRL and ensuring that a certificate you are checking against hasn’t been revoked • This is another problem with the PKI vision– no way to truly automate this with so many CAs out there! • There is a new protocol many CAs are starting to support- it essentially eliminates the download part, but the JCA/JCE doesn’t integrate with this protocol as of yet.

41. Questions & Answers • Questions?