defending against the sneakers scenario bryan sullivan ......never hard‐code classes, use abstract...

64
Defending Against the Sneakers Scenario Bryan Sullivan, Security Program Manager, Microsoft SDL

Upload: others

Post on 22-Jun-2020

7 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Defending Against the Sneakers Scenario

Bryan Sullivan, Security Program Manager, Microsoft SDL

Page 2: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Crypto systems get broken

Why assume that current algorithms really are unbreakable, unlike every other time in the 

history of cryptography?

eh vxuh wr gulqn brxu rydowlqh be sure to drink your ovaltine

Page 3: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Consequences

  Change code   Rebuild   Retest   Deploy patches to n users

  Pretty big window of attack…

Page 4: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Other concerns

  Export controls   International regulations   FIPS‐140

Page 5: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Solution

  Plan for this from the beginning

  Assume the crypto algorithms you use will be defeated in your application’s lifetime

  Code your apps in a cryptographically agile manner   Or code‐review apps for crypto agility if you’re of the pentester persuasion and not a dev

Page 6: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Steps toward crypto agility

  Step 1: Avoid hardcoded algorithms

Page 7: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Abstraction

  Want one of these?

  Are you sure?

Page 8: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

*If used correctly…

Three Cryptographically Agile Frameworks*

.NET JCA CNG Java Cryptography 

Architecture Cryptography API Next Generation

Page 9: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

.NET Cryptography

Page 10: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

.NET top‐level abstract classes

  SymmetricAlgorithm   AsymmetricAlgorithm   HashAlgorithm

  KeyedHashAlgorithm   HMAC

  RandomNumberGenerator

Page 11: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

.NET Crypto Architecture HashAlgorithm

+ComputeHash()

SHA512

SHA512Cng SHA1Managed SHA512Managed

#HashCore() +Create()

SHA1

Page 12: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

.NET examples

  Non‐agile:

  MD5Cng hashObj = new MD5Cng();   byte[] result =        hashObj.ComputeHash(data);

Page 13: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

.NET examples

  More agile:

  HashAlgorithm hashObj =       HashAlgorithm.Create("MD5");   byte[] result =        hashObj.ComputeHash(data);

Page 14: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Java Cryptography Architecture (JCA)

Page 15: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

JCA top‐level classes

  javax.crypto.Cipher   javax.crypto.KeyAgreement   java.security.KeyFactory   javax.crypto.KeyGenerator   java.security.KeyPairGenerator   javax.crypto.Mac   java.security.MessageDigest   javax.crypto.SecretKeyFactory   java.security.SecureRandom   java.security.Signature

Page 16: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

JCA Architecture

MessageDigestSpi

+engineDigest()

MessageDigest

+digest() +getInstance()

DigestBase

SHA SHA2 MD5

Page 17: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

JCA example

  More agile (by default, this is great!):

  MessageDigest md =       MessageDigest.getInstance("MD5");   byte[] result = md.digest(data);

Page 18: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

JCA Architecture

MessageDigestSpi

+engineDigest()

MessageDigest

+digest() +getInstance()

DigestBase

SHA SHA2 MD5

Page 19: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Cryptography API: Next Generation (CNG)

Page 20: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

CNG agile capabilities

  Key generation and exchange   Object encoding and decoding   Data encryption and decryption   Hashing and digital signatures   Random number generation

Page 21: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

CNG Architecture BCRYPT_HASH_INTERFACE

+GetHashInterface()

BCRYPT_HASH_FUNCTION_TABLE

HashProvider

+Version +OpenAlgorithmProvider +GetProperty +SetProperty +CloseAlgorithmProvider +CreateHash +HashData +FinishHash +DuplicateHash +DestroyHash

BCRYPT_HASH_INTERFACE

Page 22: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

CAPI example

  Non‐agile:

  HCRYPTPROV hProv = 0;   HCRYPTHASH hHash = 0;   CryptAcquireContext(&hProv,      NULL, NULL, PROV_RSA_FULL, 0);   CryptCreateHash(hProv, CALG_MD5,     0, 0, &hHash);   CryptHashData(hHash, data, len, 0);

Page 23: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

CNG example

  More agile:

  BCRYPT_ALG_HANDLE hAlg = 0;   BCRYPT_HASH_HANDLE hHash = 0;   BCryptOpenAlgorithmProvider(&hAlg,      "MD5", NULL, 0);   BCryptCreateHash(hAlg, &hHash, …);   BCryptHashData(hHash, data, len, 0);

Page 24: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Still looks hardcoded to me…

  .NET HashAlgorithm.Create("MD5");

  JCA MessageDigest.getInstance("MD5");

  CNG BCryptOpenAlgorithmProvider(&hAlg, 

"MD5", NULL, 0);

Page 25: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Steps toward crypto agility

  Step 1: Avoid hardcoded algorithms   Step 2: Reconfigure the algorithm provider

Page 26: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

MD5 SHA‐1

JCA Provider Framework

Application

Provider Framework

SHA‐1 SHA‐256

MD5 SHA‐512

Provider A Provider B Provider C

Page 27: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

MD5 SHA‐1

JCA Provider Framework

Application

Provider Framework

SHA‐1 SHA‐256

MD5 SHA‐512

Provider A Provider B Provider C

MessageDigest. getInstance ("MD5");

Page 28: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

MD5 SHA‐1

JCA Provider Framework

Application

Provider Framework

SHA‐1 SHA‐256

MD5 SHA‐512

Provider A Provider B Provider C

MessageDigest. getInstance ("MD5", "Provider C");

Page 29: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Configure providers

  Option #1: Modify java.security file (static)

  security.provider.1=     sun.security.provider.Sun   security.provider.2=     sun.security.provider.SunJCE   …

Page 30: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Configure providers

  Option #2: Add in code (dynamic)

  java.security.Provider provider =      new MyCustomProvider();   Security.addProvider(provider);

Page 31: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Scenario #1: Bad provider

    security.provider.1=foo     security.provider.2=bar

Page 32: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Scenario 2: Bad algorithm

MD5 SHA‐1

Application

Provider Framework

SHA‐1 SHA‐256

MD5 SHA‐512

Provider A Provider B Provider C

“MD5”

New Custom Provider

Page 33: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Custom provider

public class Provider   extends java.security.Provider {

  put("MessageDigest.MD5",    "MyFakeMD5Implementation"); }

Page 34: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

JCA Architecture

MessageDigestSpi

+engineDigest()

MessageDigest

+digest() +getInstance()

DigestBase

SHA SHA2 MD5

Page 35: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Fake implementation

MessageDigestSpi

+engineDigest()

FakeMD5Implementation

+digest()

SHA

Page 36: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

CNG provider framework

  Similar to JCA, but less flexible

  Custom providers go in system folder   Must register programmatically

  Can only specify top or bottom of the list

Page 37: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Fake implementation BCRYPT_HASH_INTERFACE

+GetHashInterface()

BCRYPT_HASH_FUNCTION_TABLE

FakeMD5Implementation

+Version +OpenAlgorithmProvider +GetProperty +SetProperty +CloseAlgorithmProvider +CreateHash +HashData +FinishHash +DuplicateHash +DestroyHash

BCRYPT_HASH_INTERFACE

Page 38: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Registering a custom provider

CRYPT_PROVIDER_REG providerReg =     {…}; BCryptRegisterProvider(    "FakeMD5Implementation", 0,    &providerReg); BCryptAddContextFunctionProvider(    CRYPT_LOCAL, NULL,    BCRYPT_HASH_INTERFACE, "MD5",     "FakeMD5Implementation",    CRYPT_PRIORITY_TOP);

Page 39: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Avoid hardcoded implementation

BCRYPT_ALG_HANDLE hAlg = 0; BCryptOpenAlgorithmProvider(   &hAlg,    "SHA1",   "Microsoft Primitive Provider",   0);

Page 40: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

.NET

Application

mscorlib

machine.config

HashAlgorithm.Create("MD5")

Page 41: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Altering machine.config

<configuration>  <mscorlib>     <cryptographySettings>

       <nameEntry name="MD5"             class="MyPreferredHash" />

   <cryptoClasses>     <cryptoClass      MyPreferredHash="SHA512Cng, …" />    </cryptoClasses>

Page 42: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Remapping algorithm names is dangerous

MD5 SHA‐1

  This is a good thing, right?   What could possibly go wrong?

Page 43: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Steps toward crypto agility

  Step 1: Avoid hardcoded algorithms   Step 2: Avoid hardcoded implementations   Step 3: Reconfigure the algorithm provider   Step 3 (alternate): Avoid default algorithm names

Page 44: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Unique algorithm names

  .NET     HashAlgorithm.Create(      "ApplicationFooPreferredHash");

  JCA     MessageDigest.getInstance(      "ApplicationBarPreferredDigest");

  CNG BCryptOpenAlgorithmProvider(&hAlg, 

"ApplicationFooPreferredHash", …);

Page 45: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Steps toward crypto agility

  Step 1: Avoid hardcoded algorithms   Step 2: Avoid hardcoded implementations   Step 3: Reconfigure the algorithm provider   Step 3 (alternate): Avoid default algorithm names

  Step 3 (alternate #2): Pull algorithm name from secure configuration store

Page 46: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Unique provider vs. config

Unique provider

  Pros   Security to perform this action already part of the system

  Cons   Probably prohibitive in terms of implementation cost

Configuration store

  Pros   Much easier to implement

  Cons   Must remember to secure the store!

Page 47: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()
Page 48: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

What went wrong?

  Changing the algorithms is one thing…   …but changing stored data is another.

Page 49: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Steps toward crypto agility

  Step 1: Avoid hardcoded algorithms   Step 2: Avoid hardcoded implementations   Step 3: Reconfigure the algorithm provider   Step 3 (alternate): Avoid default algorithm names

  Step 3 (alternate #2): Pull algorithm name from secure configuration store

  Step 4: Store and consume algorithm metadata

Page 50: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

What metadata to store

  Hashes   Algorithm name   Salt size   Output size   (Max input size)

  Size considerations   Local variables (ie source code)   Database columns

Page 51: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

What metadata to store

  Symmetric encryption   Algorithm name   Block size   Key size   Mode   Padding mode   Feedback size

Page 52: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

What metadata to store

  Asymmetric encryption   Algorithm name   Key sizes   Key exchange algorithm   Signature algorithm

Page 53: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

What metadata to store

  MAC   Algorithm name   Key size   Key derivation function

  Function algorithm   Salt  size   Iteration count

  Output size   (Max input size)

Page 54: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

MS‐OFFCRYPTO

  Office Document Cryptography Structure Specification

  http://msdn.microsoft.com/en‐us/library/cc313071(office.12).aspx

Page 55: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Consuming metadata: Authn

Username Password hash

Hash algorithm name Salt

  Pull metadata from database for user   Instantiate the same algorithm  originally used   Create hash from supplied password & compare   If authentic, prompt for new password   Store in new format

Page 56: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Storage considerations

DocId EncryptedContents Algorithm KeySize Mode

1 sdfER35wef23SDDp… AES 256 CBC

2 pOl089X13WasM8oi… AES 256 CBC

3 45Tr0oSd2ZaZ23lk… RC2 64 ECB

  This is wasteful

Page 57: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Storage considerations

  This is better

AlgorithmId Algorithm KeySize Mode

1 AES 256 CBC

2 RCS 64 ECB

DocId EncryptedContents AlgorithmId

1 sdfER35wef23SDDp… 1

2 pOl089X13WasM8oi… 1

3 45Tr0oSd2ZaZ23lk… 2

Page 58: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Wrap‐up

Page 59: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Other frameworks

  Bouncy Castle   Missing factory/provider functionality

  OpenSSL   Not OO

  CAPI   Providers need to be signed by Microsoft   Algorithms stored as integers, not strings

  Common Crypto   Not OO

Page 60: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Summary

  .NET   Never hard‐code classes, use abstract classes and factory pattern

  JCA   Never name specific provider in getInstance()   Never dynamically add providers

  CNG   Never name specific implementation in BCryptOpenAlgorithmProvider

Page 61: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Summary

  Reconfiguring a global algorithm name is extremely dangerous   Use as last resort and a temporary fix at best

  Store and consume algorithm metadata

  Read all formats, but write only strong crypto

Page 62: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

Q & A

Page 63: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

More resources

  http://www.microsoft.com/sdl   http://blogs.msdn.com/b/sdl

  My alias: bryansul

Page 64: Defending Against the Sneakers Scenario Bryan Sullivan ......Never hard‐code classes, use abstract classes and factory pattern JCA Never name specific provider in getInstance()

SDL Allowed Algorithms

Algorithm Type Banned

Algorithms to be replaced in existing code or used only for 

decryption 

Minimally Acceptable

Algorithms acceptable for existing code (except sensitive data) 

Recommended

Algorithms for new code 

Symmetric Block  DES, 3DES (2 key), DESX, RC2, SKIPJACK 

3DES (3 key)  AES (>=128 bit) 

Symmetric Stream 

SEAL, CYLINK_MEK, RC4 (<128bit) 

RC4 (>= 128bit)  None – Block cipher is preferred 

Asymmetric  RSA (<2048 bit), Diffie‐Hellman (<2048 

bit) 

RSA (>=2048bit), Diffie‐Hellman (>=2048bit),

ECC (>=256bit) Hash

(includes HMAC usage) 

SHA‐0 (SHA), SHA‐1, MD2, MD4, MD5 

3DES MAC  SHA‐2 (includes: SHA‐256, SHA‐384, SHA‐512)