eas309 cryptography and easerver
Download
Skip this Video
Download Presentation
EAS309 Cryptography and EAServer

Loading in 2 Seconds...

play fullscreen
1 / 41

EAS309 Cryptography and EAServer - PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on

EAS309 Cryptography and EAServer. Jason Weiss Senior Architect, Sybase OEM Engineering [email protected] August, 2003. Overview. Cryptography is something every distributed developer needs to have a basic comprehension of in today’s networked world

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' EAS309 Cryptography and EAServer' - rosa


An Image/Link below is provided (as is) to download presentation

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 - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
eas309 cryptography and easerver

EAS309 Cryptography and EAServer

Jason WeissSenior Architect, Sybase OEM [email protected], 2003

overview
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.
background
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
topics
Topics
  • JCA Provider Overview: Preparing EAServer
  • Symmetric Ciphers
  • Asymmetric Ciphers
  • Hashing, Message Digests, MACs and Digital Signatures
  • Key Stores, Certificates
jca overview
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
jce overview
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
deploying the bc provider to easerver
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
deploying the bc provider to easerver con t
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
verification of installation
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:
topics1
Topics
  • JCA Provider Overview: Preparing EAServer
  • Symmetric Ciphers
  • Asymmetric Ciphers
  • Hashing, Message Digests, MACs and Digital Signatures
  • Key Stores, Certificates
symmetric ciphers
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!
padding schemes
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
feedback modes
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
symmetric cipher areas of concern
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
symmetric cipher algorithms
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!
com sybase pbcrypt cryptops
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)
topics2
Topics
  • JCA Provider Overview: Preparing EAServer
  • Symmetric Ciphers
  • Asymmetric Ciphers
  • Hashing, Message Digests, MACs and Digital Signatures
  • Key Stores, Certificates
asymmetric ciphers
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
revisiting symmetric cipher areas of concern
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
my what a large key you have
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!
asymmetric encryption
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
com sybase pbcrypt cryptops1
com.sybase.pbcrypt.CryptOps
  • Asymmetric Cipher Code Examples:
    • String generateSecretKey(String algorithm)
    • StringencryptPlainText(Stringalgorithm,StringsecretKey,StringplainText)
    • String[] createRSAKeyPair()
    • String encryptSecretKey(String secretKeyData, String publicKey)
topics3
Topics
  • JCA Provider Overview: Preparing EAServer
  • Symmetric Ciphers
  • Asymmetric Ciphers
  • Hashing, Message Digests, MACs and Digital Signatures
  • Key Stores, Certificates
hashing defined
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
available message digests
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!
com sybase pbcrypt cryptops2
com.sybase.pbcrypt.CryptOps
  • Message Digest Code Examples
    • String getMessageDigest(String algorithm, String msg)
message digest shortcomings
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!
message authentication codes
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
com sybase pbcrypt cryptops3
com.sybase.pbcrypt.CryptOps
  • MAC Code Examples
    • String getMAC(String algorithm, String secret,String msg)
mac shortcomings
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.
digital signatures
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
digital signature process
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
digital signature choices
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
com sybase pbcrypt cryptops4
com.sybase.pbcrypt.CryptOps
  • Digital Signature Code Examples
    • String[] createRSAKeyPair()
    • String signDocument(String privateKey, String msg)
    • boolean verifySignature(String publicKey, String msg, String signatureValue)
topics4
Topics
  • JCA Provider Overview: Preparing EAServer
  • Symmetric Ciphers
  • Asymmetric Ciphers
  • Hashing, Message Digests, MACs and Digital Signatures
  • Key Stores, Certificates
the need for key management
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
powerbuilder note
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
digital certificates
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.
digital certificate generation
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!
certificate revocation list
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.
ad