Loading in 5 sec....

EAS309 Cryptography and EAServerPowerPoint Presentation

EAS309 Cryptography and EAServer

- 60 Views
- Uploaded on
- Presentation posted in: General

EAS309 Cryptography and EAServer

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

EAS309 Cryptography and EAServer

Jason WeissSenior Architect, Sybase OEM Engineeringweissj@sybase.comAugust, 2003

- 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.

- 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

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

- 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

- 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

- 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

- 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

- 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:

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

- 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!

- 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

- 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

- 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

- 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!

- 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)

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

- 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

- 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

- 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!

- 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

- Asymmetric Cipher Code Examples:
- String generateSecretKey(String algorithm)
- StringencryptPlainText(Stringalgorithm,StringsecretKey,StringplainText)
- String[] createRSAKeyPair()
- String encryptSecretKey(String secretKeyData, String publicKey)

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

- 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

- 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!

- Message Digest Code Examples
- String getMessageDigest(String algorithm, String msg)

- 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!

- 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

- MAC Code Examples
- String getMAC(String algorithm, String secret,String msg)

- “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.

- 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

- 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

- 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

- Digital Signature Code Examples
- String[] createRSAKeyPair()
- String signDocument(String privateKey, String msg)
- boolean verifySignature(String publicKey, String msg, String signatureValue)

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

- 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

- 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

- 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.

- 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!

- 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.

- Questions?