Upload
voduong
View
216
Download
0
Embed Size (px)
Citation preview
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
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….
17
Connection Request
Challenge
%#$^bkjhg)-6uRt$oP-8*
Encryption
Key
Encryption
Key
Crypto is Easy to get wrong….
18
Encryption
Key
Encryption
Key
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?
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
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.
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
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
72
Reference Links
•https://password-hashing.net/
•A new algorithm for password hashing:
Argon2
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.
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
“All trademarks used herein are the property of their respective owners”