enterprise security api (esapi) 2.0 crypto changes

Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

ESAPI Summit – OWASP AppSec USA 2011

http://www.owasp.org/

Enterprise Security API(ESAPI) 2.0 Crypto Changes

Kevin W. WallESAPI Project co-ownerkevin.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

• 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/

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

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

What's Wrong with ECB Mode?

Original Tux Image Tux Encrypted w/ ECB Mode

Encrypted w/ other than ECB

Why Do We Need Message Authenticity?

• Ensures IV + ciphertext is authentic (not tampered with)

– So what?• Umm... Padding Oracle Attack

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

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

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.

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?

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

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

...

Q&A

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