1. Enterprise Security API (ESAPI) 2.0 Crypto Changes
Kevin W. Wall
ESAPI Project co-owner
September 21, 2011 1 1

2. Obligatory CV
20+ years developer experience, 12 yrs security experience
17 yrs at (now Alcatel-Lucent) Bell Labs; left as DMTS
3.5 yrs as independent contractor (C++ & Java)
12 years application & information security experience
Currently: Staff Security Engineer at CenturyLink (formerly Qwest)
OWASP ESAPI for Java
Project co-owner
Cryptography developer (since 2.0rc2)
OWASP ESAPI for C++
Meddlesome troublemaker
Blog: 2 2

3. Why the ESAPI 2.0 Crypto Changes?
ESAPI 1.4 implementation
Default algorithm was PBEWithMD5AndDES
PBE → Keys vulnerable to dictionary attacks
Weak algorithms (DES and MD5)
Uses CBC cipher mode and PKCS5 padding
Restricted to single encryption key
Default setting for MasterSecret & MasterSalt
No message authenticity for ciphertext 3 3

4. Why the ESAPI 2.0 Crypto Changes?
ESAPI 2.0rc1 / 2.0rc2 implementations
Default algorithm was 256-bit AES
Better, but...
Uses ECB mode and no way to use another mode
Still restricted to single encryption key
Still default setting for MasterSecret & MasterSalt
Still no message authenticity 4 4

5. Tux Encrypted w/ ECB Mode Encrypted w/ other than ECB
What's Wrong with ECB Mode?
Original Tux Image
Tux Encrypted w/ ECB Mode
Encrypted w/ other than ECB 5 5

6. Why Do We Need Message Authenticity?
Ensures IV + ciphertext is authentic (not tampered with)
So what?
Umm... Padding Oracle Attack 6 6

7. Aside: Padding Oracle Attack
What is it?
First described in 2002 in context of IPSec by Serge Vaudenay
Attack on CBC mode of operation where “oracle” leaks info whether or not padding of ciphertext is correct.
Oracle typically is either different error messages being returned or timing side-channel attack.
So what's the harm?
Allows adversary to decrypt (and encrypt) data without knowledge of the secret key.
Is efficient: Works without a large “work factor”
Reference: Brian Holyfield’s NYC OWASP presentation:
Oracle_OWASP_NYC.pdf 7 7

8. Major Changes in ESAPI 2.0 Crypto
Deprecated, then removed, unsafe methods
Added support for CipherText objects
Added support for PlainText objects
Added support for multiple secret keys
Added support for message authenticity
Added support for multiple cipher modes (but using multiple ones w/in app still a kludge [potential race condition])
Changed to use strong default accessible to all
Allows AES/CBC/PKCS5Padding with 128-bit key and random IV
Authenticity generally provided by HMAC-SHA1 8 8

9. Advanced Crypto Example
So, for any of you using Google+, does this look familiar?
gpinv%3DgU47oPXLOt8%3Apox7sn5mwqF
It's an invitation to join Google+ that you to your friends. Presumably, this is a cryptographic token (although it could just be an object reference into some database).
Question: What if you wanted to implement something similar, but say for a coupon service that you could to one of your friends for some specific merchandise and you didn't want to have to store it in a database?
You could do it with an appropriate cryptographic token. 9 9

10. How much code would that take you?
Advanced Crypto Example (cont'd)
What information would you need in this cryptographic token? How about:
1) The currently authenticated user's user account name
2) The target user account name of your friend
3) A merchandise ID
4) The coupon value
5) The coupon expiration date
Of course, you want it to be secure in the following sense:
a) protection of all identities involved (confidentiality)
b) unforgeable
c) secure from tampering
d) immune to replay attacks
How much code would that take you? 10 10

11. Advanced Crypto Example (cont'd)
With ESAPI, it's something like this:
// Creating the token…
CryptoToken ctok = new CryptoToken();
ctok.setUserAccountName(
ESAPI.authenticator().getCurrentUser() );
ctok.setAttribute("targetUserAcct", targetUserName);
ctok.setAttribute("merchandiseID", merchandiseId);
ctok.setAttribute("couponPrice", price);
byte[] nonce = ESAPI.randomizer().randomBytes(16);
ctok.setAttribute("nonce", Hex.toHex(nonce, false) );
// Store nonce somewhere to prevent replays.
ctok.setExpiration( 30 * 24 * 60 *60 ); // 30 days (in secs)
return ctok.getToken(); // Return encrypted token
This example uses the default crypto key, Encryptor.MasterKey, in your ESAPI.properties file, but trivial to use an alternate SecretKey. 11 11

12. Advanced Crypto Example (cont'd)
// Consuming the token…
CryptoToken ctok = new CryptoToken(tokenString);
Date expDate = ctok.getExpirationDate();
// Check if expDate > current date and do something ...
String hexNonce = ctok.getAttribute("nonce");
// Check if nonce replayed; error if yes. Rm from table...
String targetUserName = ctok.getAttribute("targetUserAcct");
String MerchandiseId = ctok.getAttribute("merchandiseID");
String price = ctok.getAttribute("couponPrice");
// Logic to remove available coupons from originating user
String userAcctName = ctok.getUserAccountName();
...
All very straightforward. All the crypto is under the hood.
There are methods to get user account name, arbitrary attributes (by name), and the expiration time. 12 12

13. Ask now, or email me at: <kevin.w.wall@gmail.com>
Q&A
Ask now, or me at: 13 13