Eas309 cryptography and easerver
1 / 41

EAS309 Cryptography and EAServer - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
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 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

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:


  • 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

  • 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

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

  • 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

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

  • 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

  • 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

  • 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

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.