1 / 13

Enterprise Security API (ESAPI) 2.0 Crypto Changes

Enterprise Security API (ESAPI) 2.0 Crypto Changes. Kevin W. Wall ESAPI Project co-owner kevin.w.wall@gmail.com. September 21, 2011. Obligatory CV. 20+ years developer experience, 12 yrs security experience 17 yrs at (now Alcatel-Lucent) Bell Labs; left as DMTS

ojal
Download Presentation

Enterprise Security API (ESAPI) 2.0 Crypto Changes

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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

  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

  5. What's Wrong with ECB Mode?

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

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

  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

  9. Advanced Crypto Example • So, for any of you using Google+, does this look familiar? https://plus.google.com/_/notifications/ngemlink?path=%2F%3Fgpinv%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.

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

  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

  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(); ...

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

More Related