Enterprise Security API (ESAPI) 2.0 Crypto Changes Kevin W. Wall ESAPI Project co-owner kevin.w.wall@gmail.com September 21, 2011 1 1

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: http://off-the-wall-security.blogspot.com/ 2 2

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

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

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

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

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: http://blog.gdssecurity.com/storage/presentations/Padding_ Oracle_OWASP_NYC.pdf 7 7

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

Advanced Crypto Example So, for any of you using Google+, does this look familiar? https://plus.google.com/_/notifications/ngemlink?path=%2F%3F gpinv%3DgU47oPXLOt8%3Apox7sn5mwqF It's an invitation to join Google+ that you email 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 email 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

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

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

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

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