Transcript

Cryptography

Deciphering Cryptography And Its

Business Impact to You

August 10th 2016

Biography • Javed Samuel - Technical Director at NCC Group

• Lead Resource for Training Services and

Cryptography Services

• Technical Account Manager for various clients

• Deliver security assessments (eg. Architecture

Reviews, Cloud, Cryptography)

• Former Developer

2

Abstract

• Review cryptographic knowledge without too

much Math.

• Provide an understanding of important

cryptography paradigms

• Discuss exploitable cryptographic

vulnerabilities and problematic design choices.

3

Abstract

• Focus on the right cryptography questions to

ask during vendor selection or design review.

• Understand the impact and cost of wrong

cryptography choices.

4

Introduction to Cryptography

6

Cryptography Introduction

•Cryptography is an underpinning of every

organization's data security.

• It is as simple as correct deployment of

TLS

• Or possibly as complicated as bespoke

protocols for software updates or

advanced key management.

7

Cryptography Introduction

•OWASP 2010 Top Ten report of the most

critical web application security risks,

“Insecure Cryptographic Storage” made

the list at #7 .

• Follow-up report in 2013 ranked the risk

at #6 under the expanded umbrella of

“Sensitive Data Exposure.”

8

Cryptography Introduction

•The need for cryptographic review is

growing as it becomes a higher priority in

application security risk assessments.

•Cryptographic weaknesses may go

unnoticed for a long time and have

significant consequences.

9

Cryptography In the News

• iPhone Encryption

(http://blog.cryptographyengineering.com/2014/10/why-cant-

apple-decrypt-your-iphone.html )

• Airplane Security

(https://securityledger.com/2015/04/hacker-on-a-plane-fbi-

seizes-researchers-gear/ )

• Certificate Authority Compromise

(http://googleonlinesecurity.blogspot.co.nz/2015/03/maintaini

ng-digital-certificate-security.html?m=1 )

10

Cryptography In the News

• Heartbleed (http://heartbleed.com/ and

https://cryptoservices.github.io/openssl/2015/03/09/openssl-

audit.html )

• Encryption is it good or bad

(http://www.washingtonpost.com/world/national-security/as-

encryption-spreads-us-worries-about-access-to-data-for-

investigations/2015/04/10/7c1c7518-d401-11e4-a62f-

ee745911a4ff_story.html

• Bug Bounty Programs (https://info.ssl.com/bug-bounty-

programs-are-beneficial/)

11

Security of Algorithms • “Security by Obscurity”

• “Schneier’s Law”:

• Anybody can devise an encryption system

that they are not smart enough to defeat.

• Hide a million dollars in a shoebox and bury it

in the woods.

12

Security of Algorithms • Security through tested resistance to attack

• Place a million dollars in a safe.

• Give me the safe, but not its combination.

• Give me the blueprints to the safe, and its lock,

and ten identical safes and their combinations.

13

Cryptography Guidelines

•First rule of writing crypto code:

•Don’t write your own crypto code

•Second rule:

•Don’t violate #1

14

Cryptography Guidelines

•First rule of writing crypto code:

•Don’t write your own crypto code

•Second rule:

•Don’t violate #1

Crypto is Easy to get wrong….

15

Connection Request

Challenge

Alice,myP@55w0rd

Crypto is Easy to get wrong….

16

Crypto is Easy to get wrong….

17

Connection Request

Challenge

%#$^bkjhg)-6uRt$oP-8*

Encryption

Key

Encryption

Key

Crypto is Easy to get wrong….

18

Encryption

Key

Encryption

Key

Path of Least Resistance…

19

http://xkcd.com/538/

Cryptography Constructs

21

Symmetric Encryption

•Uses a single key for both encryption and

decryption

•Examples

•Addition modulo 26

•XOR with One-time pad

22

Locked Box

• A wants to send a secure message to B

• A and B each have a copy of a key for the box

• A puts a message in the box and locks it

• The box is delivered to B

• B uses the key to unlock the box and retrieve

message

23

Requirements

•A strong lock and a strong box

•A and B have the only copies of the key

•Secure Key Exchange: They must obtain

their copies in a secure way

24

Possible Attacks

•A pick or crowbar or sledgehammer on the

box: exploit weaknesses of the box or lock

design

•Make a copy of every possible key that will

fit the box until one opens it

• “Keyspace” determined by lock design;

number of tumblers, etc.

25

Encryption Parallels

•The strength of the box and lock is the

strength of the algorithm.

•The encryption keys must be as secure as

their physical analogues

26

Attacks

• Crypt-analytical attack based on some knowledge

of the algorithm, “Known Plaintext” attack, known

characteristics of Plaintext to deduce the key

• “Brute force” attack, trying every possible key in

the “keyspace”

• On average, half the keys in the keyspace

need to be tried for success

• Keyspace is determined by the bit-length of

the key

27

Public Key Encryption

•First introduced by Whitfield Diffie and

Martin Hellman in 1976

•The first truly revolutionary development in

cryptography in thousands of years.

•Based on mathematical functions rather

than simple arithmetic or “bit-wise”

operations

28

Public Key Encryption

•First introduced by Whitfield Diffie and

Martin Hellman in 1976

•The first truly revolutionary development in

cryptography in thousands of years.

•Based on mathematical functions rather

than simple arithmetic or “bit-wise”

operations

29

Public Key Encryption

•Uses two keys; one for encryption and one

for decryption

•Use of two keys also provides

authentication

30

Public Key Encryption Misconceptions

• It is more secure than Conventional Encryption

• There is nothing inherent in Public Key

algorithms which renders them more resistant

to cryptanalytic attack.

• It is a replacement for Conventional Encryption

• It is several orders of magnitude slower than

conventional encryption - not practical for use

with large messages/files.

• PGP uses a combination of Public Key and

Conventional/Symmetric encryption.

Lock Box Analogy A and B each have a DIFFERENT key to a special Lock Box

The keys are related, in that each can “undo” the work of the other

Assume the box has a special lock, such that the center position is unlocked.

A has a key that can turn the lock clockwise

B has a key that can turn the lock counter-clockwise

31

Public Key Encryption

A can now have numerous identical boxes, and give out copies

of the counter-clockwise key to whomever he wishes to

securely correspond with. Since he retains the only copy of the

clockwise key, only he can open the boxes once they are

locked.

32

A

Public Key Encryption Similarly, B has numerous boxes with special locks

and keys, and gives a box and a counter-clockwise

key to A. Now they can correspond securely.

33

B

Public Key Encryption

BIG ADVANTAGE over symmetrical encryption; key

management is much simpler.

With symmetrical encryption, A must have a separate,

secret, symmetrical key for each correspondent. And

they must find a secure way to share/exchange this

key.

Caveat: It is critical to make sure that the Public Key’s

used for encryption in fact belong to the intended

correspondent, and not an impostor!

34

Public Key Encryption

Authentication:

A writes a message, and puts it in a box which he locks

with B’s counter-clockwise (public) key. This means that

only B can open it to read the message.

A then places this box inside one of his own boxes,

which he locks with his own clockwise (private) key.

35

B’s Box and Public Key

Message

A’s Box and Private Key

36

Public Key Encryption - RSA

Select two prime numbers: p and q

Let n = pq

f(n) = (p-1) ( q-1)

Select e, such that:

1 < e < f(n), and:

e is relatively prime to f(n); i.e., gcd (e, f(n)) = 1

Compute d = e-1 mod f(n)

or: de mod f(n) = 1

37

Public Key Encryption - RSA

•Given e and n, it is very difficult to deduce

d. The problem involves factoring n, a very

large product of two very large primes.

•When PGP generates a 2048 bit key, at

generates two 1024 bit primes whose

product is 2048 bits.

•There are approximately 1.7 x 10305

1024-bit primes

38

Public Key Encryption - RSA

•Me mod n = C (Encryption)

•Cd mod n = M

•Md mod n = S (Signature)

•Se mod n = M

39

Encryption != Integrity Protection

•Encrypting data makes data private.

•Even when it’s encrypted, data can still be

modified without detection, possibly

resulting in meaningful data.

40

Encryption != Integrity Protection

•Our Algorithm: AES

•Our Key: 0123456789ABCDEF

•Our UserID: 1111111111111111

•Our Cipher Text : 17668DFC7292532D

41

Encryption != Integrity Protection

•Our Cipher Text: 17668DFC7292532D

•Our ‘Bit Flip’: 27668DFC7292532D

•Our New UserID: 8795A2EA3DF937F8

•What if our New UserID is valid?

•Can you tell it has been tampered with?

42

Solutions

•Message Authentication Code (MAC)

•Hash Based Message Authentication Code

(HMAC)

•Authenticated Encryption (AE)

43

Secure Hash Functions

• A Digital Hash, is essentially a digest or

“fingerprint” of a file, such that:

• It is unique to that file [dependent on the hash

size]

• It must use the entire message for

computation, so that alterations can not be

made without changing the hash value

• It must be relatively easy to compute, to make

it practical

• It must work on any size file

• It is infeasible to recreate the file from the hash

44

Secure Hash Functions

• The length of the Hash Value is critical

• If a Hash value is only 8 bits long, there are

only 256 possible values, thus many different

messages will produce the same hash value.

• If a hash value is 32 bits long, there are

4,294,967,296 possible hash values. Is this

secure?

Cryptography Vulnerabilities

46

Randomness

• Insufficient Randomness leading to

predictable values.

•How is my PRNG seeded?

•Am I using OS randomness?

•Know your scheme and what sort of

randomness it expects.

47

Key Management

•Keys generated insecurely.

•Keys stored in insecure locations such as

files accessible to attacker

• Inability to revoke keys

48

Correct Cipher Mode

•Do not use ECB mode encryption

•ECB mode leaves patterns in data intact

•Using CBC mode ensures proper

randomization of data

49

Correct Cipher Mode

Original ECB Mode Encrypted Securely Encrypted

50

Correct Cipher Mode

• Issue

• Each block is XORed with previous block of

ciphertext. First block is still plaintext.

• CBC Solution

• Use an ‘initialization vector’ for the first block.

You generate a block of completely random

data for the first block. If you see an

initialization vector in a block cipher API, fill it

with data from a secure random number

generator.

51

Integrity Concerns

• If you see CRC32 used anywhere – be suspicious

• Engineers don’t worry about lower layers

anymore

• If you see a raw hash function used anywhere

except password hashing – be suspicious

• Lots of people think hash functions convey

integrity in the face of the attacker

• If you see any data that leaves complete control of

the data owner – it should probably be MACed

• An entire talk could be devoted to problems with

password storage. Very hard to do correctly.

• The past few years have had a flood of stories of

companies with poor password storage and you

want to be sure you are not one of them.

Password Storage:

Even Easier to Screw Up

A few companies with password databases stolen in the past few

years:

Password Storage:

Even Easier to Screw Up

• It’s best to assume that your password database

*will* be stolen and put on Twitter.

•That way if it is, you’ve secured it well enough that the

attackers wont be able to retrieve the passwords.

• Many companies do this poorly. Doing it well puts

you in a whole other class.

Password Storage:

Even Easier to Screw Up

Threat: Attackers retrieve the password database

through SQL injection attack, memory corruption

attack, shell injection or other.

If you store your passwords in plaintext, the attackers

will have all your users’ passwords.

Password Storage:

Even Easier to Screw Up

• First Attempt: Run SHA-1 on the passwords, store

SHA-1 hash in database. Hash incoming

passwords and compare the hashes.

• Pretty easy to crack. Hackers make giant multi-

terabyte tables of common passwords to their

SHA-1 hashes, and look up the hashes in your

database. This is called a rainbow table.

Password Storage:

Even Easier to Screw Up

• Second Attempt: Add a single salt to the hash. A salt is

a random number hashed along with each password. If

the salt is random, the attacker will not have a rainbow

table for it.

• Hackers can create a rainbow table for that salt pretty

quickly.

Password Storage:

Even Easier to Screw Up

• Third attempt: per-user salt. Hackers will have to

create a per-user rainbow table.

• This one is better. We can make some

improvements, though.

Password Storage:

Even Easier to Screw Up

• Hash the password many times.

• The idea is to slow down the operation of hashing

the password.

• This presents only a miniscule delay for a user,

who is only going to type their password a few

times, whereas an attacker needs to try thousands

of passwords.

Password Storage:

Even Easier to Screw Up

• It’s still hard to know how many times to hash it

to keep up with current hardware.

• If the password is for an important enough

account, attackers can just use a botnet to

distribute cracking.

Password Storage:

Even Easier to Screw Up

• It’s easier to use a library to do all this.

• Do not use your own password hashing functions.

• Bcrypt library – Niels Provos and David Mazieres

• Bcrypt was written with just this in mind. It’s

important to know how all the above attacks work,

but Bcrypt handles the details for you.

Password Storage:

Even Easier to Screw Up

Password Storage

Key Takeaways:

Store the passwords as if your password storage is completely public.

Use Bcrypt, PBKDF2, Scrypt.

• You actually want the hash to be slow. It takes relatively little time to run a slow hash when a user is logged in, but the short delay introduces impossible obstacles for attackers.

• It’s tunably slow. As computers get faster, it can be tuned to be slower.

Cryptography Vendor Reviews

64

What should I do?

•Review the functional and design

documentation describing the usage of

core cryptographic components.

•Both security and functional

requirements customized to the

particular deployment of these

cryptographic implementations.

65

What should I do?

•Analyze the planned use cases and

assurances desired of the cryptosystem in

comparison to the design documents and

libraries in use.

66

Cryptographic Threats

• Identify threats to the cryptosystem and the

risks associated with threats, such as ways

for an attacker to:

• Obtain inappropriate access to cryptographic

keys

• Make unauthorized changes to algorithms or

keying material, or data

• Bypass authentication and authorization

mechanisms

67

Cryptographic Review

•Review the key provisioning, distribution,

and key management

•Review use of data encryption at-rest and

in-transit

•Evaluate whether secure randomness is

used

•Evaluate encryption algorithms in use

68

Cryptographic Parameters

• Initialization Vectors and Nonces

•Block Cipher Mode

•Key Length

•Hash Functions chosen

•Authenticated Data

Cryptography References

70

Reference Links

Messaging / Curves -

https://moderncrypto.org/

Adam Langley, Trevor Perrin, Nate Lawson,

Cem Paya, Matt Green, djb, Joux, Kenny

Paterson

NCC resources

https://cryptoservices.github.io/ and

http://cryptologie.net/

71

Reference Links

• IETF: TLS, Trans, HTTP-Auth, CFRG,

WebSec

• java-sec-dev, Bitcoin, CADO-NFS

•Metzdowd, Randombit, P2P-Hackers,

SimSec

• IACR ePrint

•Twitter

73

Conclusion

•Review cryptography used in your

application and infrastructure.

•Avoid custom cryptography and use

standards based approach.

•Build for the future since cryptography is

constantly evolving.

Questions on anything Crypto related

75

Locations

Europe

Manchester - Head Office

Amsterdam

Basingstoke

Cambridge

Copenhagen

Cheltenham

Edinburgh

Glasgow

Leatherhead

Leeds

London

Luxembourg

Milton Keynes

Munich

Wetherby

Zurich

Australia

Sydney

North America

Atlanta

Austin

Chicago

New York

San Francisco

Seattle

Sunnyvale

76

Points of contact

Javed Samuel

Technical Director

NCC Group Security Services

M: 650-763-6449

E: [email protected]

“All trademarks used herein are the property of their respective owners”


Top Related