Defending Against the Sneakers Scenario Bryan Sullivan, Security - - PowerPoint PPT Presentation

defending against the sneakers scenario bryan sullivan
SMART_READER_LITE
LIVE PREVIEW

Defending Against the Sneakers Scenario Bryan Sullivan, Security - - PowerPoint PPT Presentation

Defending Against the Sneakers Scenario Bryan Sullivan, Security Program Manager, Microsoft SDL Crypto systems get broken eh vxuh wr gulqn brxu rydowlqh be sure to drink your ovaltine Why assume that current algorithms really are unbreakable,


slide-1
SLIDE 1

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

slide-2
SLIDE 2

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

slide-3
SLIDE 3

Consequences

  • Change code
  • Rebuild
  • Retest
  • Deploy patches to n users
  • Pretty big window of attack…
slide-4
SLIDE 4

Other concerns

  • Export controls
  • International regulations
  • FIPS‐140
slide-5
SLIDE 5

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

slide-6
SLIDE 6

Steps toward crypto agility

  • Step 1: Avoid hardcoded algorithms
slide-7
SLIDE 7

Abstraction

  • Want one of

these?

  • Are you sure?
slide-8
SLIDE 8

*If used correctly…

Three Cryptographically Agile Frameworks*

.NET JCA CNG

Java Cryptography Architecture Cryptography API Next Generation

slide-9
SLIDE 9

.NET Cryptography

slide-10
SLIDE 10

.NET top‐level abstract classes

  • SymmetricAlgorithm
  • AsymmetricAlgorithm
  • HashAlgorithm

 KeyedHashAlgorithm

 HMAC

  • RandomNumberGenerator
slide-11
SLIDE 11

.NET Crypto Architecture

HashAlgorithm +ComputeHash() SHA512 SHA512Cng SHA1Managed SHA512Managed #HashCore() +Create() SHA1

slide-12
SLIDE 12

.NET examples

  • Non‐agile:

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

slide-13
SLIDE 13

.NET examples

  • More agile:

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

slide-14
SLIDE 14

Java Cryptography Architecture (JCA)

slide-15
SLIDE 15

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
slide-16
SLIDE 16

JCA Architecture

MessageDigestSpi +engineDigest() MessageDigest +digest() +getInstance() DigestBase SHA SHA2 MD5

slide-17
SLIDE 17

JCA example

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

MessageDigest md =

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

slide-18
SLIDE 18

JCA Architecture

MessageDigestSpi +engineDigest() MessageDigest +digest() +getInstance() DigestBase SHA SHA2 MD5

slide-19
SLIDE 19

Cryptography API: Next Generation (CNG)

slide-20
SLIDE 20

CNG agile capabilities

  • Key generation and exchange
  • Object encoding and decoding
  • Data encryption and decryption
  • Hashing and digital signatures
  • Random number generation
slide-21
SLIDE 21

CNG Architecture

BCRYPT_HASH_INTERFACE +GetHashInterface() BCRYPT_HASH_FUNCTION_TABLE HashProvider +Version +OpenAlgorithmProvider +GetProperty +SetProperty +CloseAlgorithmProvider +CreateHash +HashData +FinishHash +DuplicateHash +DestroyHash

BCRYPT_HASH_INTERFACE

slide-22
SLIDE 22

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

slide-23
SLIDE 23

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

slide-24
SLIDE 24

Still looks hardcoded to me…

  • .NET

HashAlgorithm.Create("MD5");

  • JCA

MessageDigest.getInstance("MD5");

  • CNG

BCryptOpenAlgorithmProvider(&hAlg, "MD5", NULL, 0);

slide-25
SLIDE 25

Steps toward crypto agility

  • Step 1: Avoid hardcoded algorithms
  • Step 2: Reconfigure the algorithm provider
slide-26
SLIDE 26

MD5 SHA‐1

JCA Provider Framework

Application Provider Framework

SHA‐1 SHA‐256 MD5 SHA‐512 Provider A Provider B Provider C

slide-27
SLIDE 27

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

slide-28
SLIDE 28

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

slide-29
SLIDE 29

Configure providers

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

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

slide-30
SLIDE 30

Configure providers

  • Option #2: Add in code (dynamic)

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

slide-31
SLIDE 31

Scenario #1: Bad provider

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

slide-32
SLIDE 32

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

slide-33
SLIDE 33

Custom provider

public class Provider extends java.security.Provider { put("MessageDigest.MD5", "MyFakeMD5Implementation"); }

slide-34
SLIDE 34

JCA Architecture

MessageDigestSpi +engineDigest() MessageDigest +digest() +getInstance() DigestBase SHA SHA2 MD5

slide-35
SLIDE 35

Fake implementation

MessageDigestSpi +engineDigest() FakeMD5Implementation +digest() SHA

slide-36
SLIDE 36

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

slide-37
SLIDE 37

Fake implementation

BCRYPT_HASH_INTERFACE +GetHashInterface() BCRYPT_HASH_FUNCTION_TABLE FakeMD5Implementation +Version +OpenAlgorithmProvider +GetProperty +SetProperty +CloseAlgorithmProvider +CreateHash +HashData +FinishHash +DuplicateHash +DestroyHash

BCRYPT_HASH_INTERFACE

slide-38
SLIDE 38

Registering a custom provider

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

slide-39
SLIDE 39

Avoid hardcoded implementation

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

slide-40
SLIDE 40

.NET

Application mscorlib machine.config

HashAlgorithm. Create("MD5")

slide-41
SLIDE 41

Altering machine.config

<configuration> <mscorlib> <cryptographySettings> <nameEntry name="MD5" class="MyPreferredHash" /> <cryptoClasses> <cryptoClass MyPreferredHash="SHA512Cng, …" /> </cryptoClasses>

slide-42
SLIDE 42

Remapping algorithm names is dangerous

MD5 SHA‐1

  • This is a good thing, right?
  • What could possibly go wrong?
slide-43
SLIDE 43

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

slide-44
SLIDE 44

Unique algorithm names

  • .NET

HashAlgorithm.Create( "ApplicationFooPreferredHash");

  • JCA

MessageDigest.getInstance( "ApplicationBarPreferredDigest");

  • CNG

BCryptOpenAlgorithmProvider(&hAlg, "ApplicationFooPreferredHash", …);

slide-45
SLIDE 45

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

slide-46
SLIDE 46

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!

slide-47
SLIDE 47
slide-48
SLIDE 48

What went wrong?

  • Changing the algorithms is one thing…
  • …but changing stored data is another.
slide-49
SLIDE 49

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

slide-50
SLIDE 50

What metadata to store

  • Hashes

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

  • Size considerations

 Local variables (ie source code)  Database columns

slide-51
SLIDE 51

What metadata to store

  • Symmetric encryption

 Algorithm name  Block size  Key size  Mode  Padding mode  Feedback size

slide-52
SLIDE 52

What metadata to store

  • Asymmetric encryption

 Algorithm name  Key sizes  Key exchange algorithm  Signature algorithm

slide-53
SLIDE 53

What metadata to store

  • MAC

 Algorithm name  Key size  Key derivation function

 Function algorithm  Salt size  Iteration count

 Output size  (Max input size)

slide-54
SLIDE 54

MS‐OFFCRYPTO

  • Office Document Cryptography Structure

Specification

  • http://msdn.microsoft.com/en‐us/library/

cc313071(office.12).aspx

slide-55
SLIDE 55

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
slide-56
SLIDE 56

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
slide-57
SLIDE 57

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

slide-58
SLIDE 58

Wrap‐up

slide-59
SLIDE 59

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

slide-60
SLIDE 60

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

slide-61
SLIDE 61

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
slide-62
SLIDE 62

Q & A

slide-63
SLIDE 63

More resources

  • http://www.microsoft.com/sdl
  • http://blogs.msdn.com/b/sdl
  • My alias: bryansul
slide-64
SLIDE 64

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)