Cryptography
Three methods:
Symmetric key
Asymmetric key
Hashing
1
Symmetric Key Encryption
• Encryption of almost everything
Data at rest: disk encryption, files, data bases
Data in motion: SSL/TLS, IPsec
• Today’s standards
Advanced Encryption Standard: AES-128 and AES-256
Processor hardware acceleration for
Galois/Counter Mode (GCM)
< 1% performance impact
• SDP/PA use AES-256 for
Single Packet Authorization
TLS communication
• Shared key encryption
The same key used to encrypt, also decrypts
Must be kept secret !!!
Very difficult to transmit a secret across an untrusted network
2
Asymmetric Key (a.k.a. Public Key) Cryptography
• Purpose
Exchange secrets over an untrusted network
Secretly (encrypted) and with integrity (signed)
• Only encrypts small pieces of data
Message must be smaller than the asymmetric key
• Only used for 2 things
Encrypt symmetric keys (common for data at rest)
Encrypt hashes (together known as a “signature”)
• Today’s standards
Diffie-Hellman, RSA (PKCS#1), Digital Signature Standard (DSS)
• SDP/PA use asymmetric key encryption for:
Encrypting keys on disk
Exchanging symmetric keys & creating signatures for the TLS handshake
Generating and validating X.509 certificates
3
Hash (a.k.a. Message Authentication Code or MAC)
• Converts an arbitrarily long message into a single number
The number is “Unique”– typical values are 2256, 2384, 2512
2256 = 1157920892373160000000000000000000000000000000000000000000000000000000000000000
Approx. # atoms in observable universe
• Cannot be reversed
Once converted to a hash, cannot be convert back into the message
Re-hash the message and compare hashes
Same hash means same message
• Today’s standards
Secure Hash Algorithm 1 (SHA-1) – widely used, considered insecure
SHA-2 family of hashes, typical use: 256, 384, 512-bit
SHA-3 released Aug 5, 2015
Message Digest 5 (MD5) – considered cryptographically broken
Key Derivation Function (KDF)
Km = create master key
K1 = H[Km]
K2 = H[K1]
K3 = H[K2]
K4 = H[K3]
• SDP/PA use hashing for:
One Time Password (OTP) and GMAC of Single Packet Authorization (SPA)
Integrity of TLS handshake
X.509 certificates (prior to being encrypted with asymmetric keys)
Derivation of TLS symmetric keys and Initialization Vectors (IV)
4
Cryptography
• Only 3 methods
Symmetric key encryption
Asymmetric key encryption
Hashing (MAC)
• Almost always used in combination
• Example
Method for SSL/TLS connection
Generate
asymmetric keys
TLS suite
cypher suite
Exchange
asymmetric keys
Symmetric key
encryption
Symmetric
key &
hashing
Hash
Authentication via
asymmetric & hashing
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
5
Symmetric Key Encryption
with Message Authentication
6
Symmetric Key Encryption
Untrusted
Network
PT
Ek
Cypher Text (CT)
Dk
PT
7
Symmetric Key Encryption & Block Cyphers
Untrusted
Network
PT
0
1
Cypher Text (CT)
Ek
2
0 0 0 0 0 1 0 1 0 0 1 1
XOR
1 1 0 0 1 0 1 1 1 1 0 1
CT
1 1 0 0 1 1 1 0 1 1 1 0
3
5
PT
3
PT
6
Dk
6
8
Symmetric Key Encryption & Block Cyphers
Untrusted
Network
PT
0
1
Cypher Text (CT)
Ek
2
Dk
3
6
PT
3
5
6
PT
0 0 0 0 0 1 0 1 0 0 1 1
CT
1 1 0 0 1 1 1 0 1 1 1 0
XOR
1 1 0 0 1 0 1 1 1 1 0 1
XOR
1 1 0 0 1 0 1 1 1 1 0 1
CT
1 1 0 0 1 1 1 0 1 1 1 0
PT
0 0 0 0 0 1 0 1 0 0 1 1
6
3
5
6
0
1
2
3
9
Symmetric Key Encryption & Message Authentication
Untrusted
Network
PT
0
1
Cypher Text (CT)
Ek
2
Dk
3
6
PT
3
5
6
PT
0 0 0 0 0 1 0 1 0 0 1 1
CT
1 1 0 0 1 1 1 0 1 1 1 0
XOR
1 1 0 0 1 0 1 1 1 1 0 1
XOR
1 1 0 0 1 0 1 1 1 1 0 1
CT
1 1 0 0 1 1 1 0 1 1 1 0
PT
0 0 0 0 0 1 0 1 0 0 1 1
6
3
5
6
0
1
2
3
10
Symmetric Key Encryption & Message Authentication
Untrusted
Network
PT
6
CT
3
Cypher Text (CT)
Ek
5
6
CT
Input XOR out Hash
6
6
7
3
4
3
6
1
7
5
PT
6
1 1 0 0 1 1 1 0 1 0 1 1
5
6
Dk
Hi
Function
XOR
0
6
Func
Hi-1
0
2
1
5
2
6
3
4
4
3
5
1
6
77
7
0
3
5
6
1 1 0 0 1 1 1 0 1 0 1 1
Input
6
3
XOR
6
4
Hash
7
3
5
6
6
1
7
5
11
Galois/Counter Mode (GCM)
and GMAC
12
Galois/Counter Mode (GCM) and GMAC
0128
IV ||
1 1
IV ||
n n
IV || 032
Ek
Ek
Ek
Ek
PT1
GHASH0
PTn
AD1
ADm
CT1
CTn
len(AD)
|| len(PT)
len(PT)
GHASH1
GHASHm
GHASHm+1
GHASHm+n
GHASH
Ek is the encryption algorithm and key, which is AES 256
PT is Plain Text that gets encrypted into Cypher Text (CT)
All blocks are 128 bits in length
IV is a 96-bit Initialization Vector, which is a nonce
1st counter block is the IV followed by the 32-bit number “1”
The output is the Cypher Text and the Tag
AD is Additional Data (that does not get encrypted)
TAG
13
Asymmetric Key Cryptography
(Public Key)
14
Asymmetric Key Cryptography
• Algorithms generate 2 keys
Private key is kept private, public key is shared
Elliptic curve keys are hundreds of bits
RSA keys are thousand bits
Message smaller than the key
Concerns:
1. How does Alice know it’s Bob’s key?
Answer: Public Key Infrastructure
• 2 uses
2. If the conversation is recorded
And if Bob’s private key is compromised
Then attacker can decrypt message
Solution: Perfect Forward Secrecy
Encrypt a symmetric key
Alice encrypt the symmetric key with Bob’s public key
So Bob can decrypt with his private key
Encrypt a hash (MAC)
Alice encrypt the hash with Alice’s private key
So Bob can decrypt it with Alice’s public key
Math Example (RSA)
Alice
Message
Encryption
Cypher Text
Decryption
Message
m
me mod n
c
cd mod n
m
For example:
Symmetric key
“e” is Bob’s
public key
Untrusted
Network
Bob
“d” is Bob’s
Private key
(me)d ≡ me*d ≡ m1 ≡ m (mod n)
15
Perfect Forward Secrecy
• Compromise of long term key
Alice
Does not compromise past keys
• Thought exercise/analogy
Diffie-Hellman Ephemeral (DHE)
But with buckets of paint*
• Thought exercise/small numbers
Also from Wikipedia
Remember this is not RSA math
+
a=6
=
A = 5^6 mod 23 = 8
Each separately blends their secret
color with the common color
b = 15
=
B = 5^15 mod 23 = 19
Blends
19
+
* Wikipedia “Diffie–Hellman key exchange”
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
+
Both choose a secret color
Exchange
• Perfect Forward Secrecy
Not encrypted key sent to another
Random keys, neither knows both
Bob
g = common # = 5
p = modulus = 23
Both agree on a common color
Each now has the other’s blended color
Each separately blends their secret
color with the other’s blended color
=
19^6 mod 23 = 2
8
+
=
Both arrive at the same
common blended color
(a common secret)
8^15 mod 23 = 2
16
Asymmetric Key Summary
• 2 uses of asymmetric key
Encrypt symmetric key (using receiver’s public)
Encrypt hashes (using sender’s private)
• RSA math
(me)d ≡ me*d ≡ m1 ≡ m (mod n)
Crypto of symmetric keys and hashes
• Diffie-Hellman analogy
Paint buckets
(ga)b (mod n) ≡ (gb)a (mod n)
Perfect Forward Secrecy
Becomes basis for pre-master key
17
Public Key Infrastructure (PKI)
18
Public Key Infrastructure (PKI)
• What is it used for?
Create and distribute digital certificates
Acts as a trusted 3rd party
Enables authentication over an untrusted network
Certificate Authority
(Trusted 3rd Party)
• SDP/PA use it for
Mutual Authentication of:
Clients to Controllers
Clients to Gateways
Gateways to Controllers
Basically, all trust
Mutual trust, not just single-ended
Mutual
Authentication
Untrusted
Network
1. Private Key
2. Public key / Certificate
3. Trusted Root certificate
1. Private Key
2. Public key / Certificate
3. Trusted Root certificate
• How does it work?
19
Initialization of PKI Certificate Authority (CA)
Root Cert
Root Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Vidder
issuer:
Vidder
Hash
Vidder Public
---------------Signature
CRL
CA
OCSP
20
Server Gets a Private Key and Certificate
Root Cert
Server Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Server
issuer:
Vidder
Hash
Server Public
---------------Signature
CRL
CA
OCSP
Server Cert
subj: Server
issuer: Vidder
Server Public
---------------Signature
21
PKI Part of TLS
Root Cert
OCSP Response
CRL
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
Valid certifacate
Not expired
Not revoked
Cert is trusted !!!
Good
CA
Serial #
Validity
Time
Hash
Good
---------------Signature
OCSP
Server Cert
Hash
Hash
Serial #
Equal ?
Equal ?
Original Hash
Original Hash
subj: Server
issuer: Vidder
Server Public
---------------Signature
Root Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
22
Client Certificate
Client
Universal ID
Pinned to SDP
Rest of Cert
Subject
Issuer
Serial #
Hash for
Signature
Public Key
Key Usage
see RFC 5280 pg. 29
Signature
(not Hashed)
23
Is PKI Broken?
• Is it broken? No
The technology is sound
Certificate Authority
(Trusted 3rd Party)
• Is it broken in some other way? Yes
The hundreds of certificate authorities should not be trusted
DigiNotar compromised – Google’s email service was compromised in Iran
Root cert injection creates additional trusted websites
Sophisticated attack that undermines trust
Certificate subject is a name, not an IP address
DNS spoofing can fool PKI
Requires revocation checking
Enables DoS attack of the infrastructure
Mutual
Authentication
Untrusted
Network
1. Private Key
2. Public key / Certificate
3. Trusted Root certificate
1. Private Key
2. Public key / Certificate
3. Trusted Root certificate
• Does Vidder fix it? Yes
Dedicated PKI means only the SDP’s certificate authority is trusted
Additional root certs cannot be injected – the one and only root is encrypted on disk
Certificate subject is an IP address, not a name – spoofing is not possible
OCSP responses are “stapled” – defeating DoS attacks
24
PKI Summary
• PKI’s purpose is to
Create and distribute digital certificates
Act as a trusted 3rd party
Enables authentication over an untrusted network
Certificate Authority
(Trusted 3rd Party)
• PKI consists of a root cert and certs derived from it
Everyone inherently trusts the root
• Certificates can be cryptographically proven
Signing proves the certificated hasn’t been altered
Signature: encrypts the hash with issuer’s private key
Creates a chain of trust that must be validated
Mutual
Authentication
Untrusted
Network
1. Private Key
2. Public key / Certificate
3. Trusted Root certificate
1. Private Key
2. Public key / Certificate
3. Trusted Root certificate
• The public implementation of PKI is “broken”
But the technology is not
SDP’s implementation fixes the breakage
25
SDP Device Authentication
1. SPA
2. Mutual TLS
3. Fingerprint
26
SDP Device Authentication
Single Packet Authorization (SPA)
27
Attacks on SSL/TLS
Name
SSLstrip
DigiNotar
THC-SSL-DOS
BEAST
CRIME
Lucky 13
TIME
RC4 biases
BREACH
goto fail
Triple Handshake
Heartbleed
BERserk
Poodle
Poodle++
FREAK
Bar-mitzvah
logjam
Date
Feb 2009
Sept 2011
Oct 2011
Apr 2012
Sept 2012
Feb 2013
Mar 2013
Mar 2013
Aug 2013
Feb 2014
Mar 2014
Apr 2014
Sept 2014
Oct 2014
Dec 2014
Mar 2015
Mar 2015
May 2015
Attack
http to https
MitM forged certs
DoS attack on SSL
Java Applet oracle
MitM SPDY compressing oracle
MitM CBC padding oracle
Browser JavaScript timing oracle
MitM RC4 oracle
Website redirect, compression
MitM counterfeit key via coding error
Server MitM on client cert
OpenSSL bug
MitM PKCS#1.5 padding
MitM SSLv3 oracle
MitM JavaScript timing oracle
MitM negotiation 512 bit key
View RC4
MitM downgrade to 512 bit key
Unauthorized
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
SPA
Authorized Users
No http
Pinned certs
Device deleted
Client-based
No compression
GCM
Client-based
No cypher negotiation
No redirect or compression
Pinned dedicated cert
Pinned dedicated cert
Not single-ended SSL
Not Mozilla NSS
No cypher negotiation
Client-based
No key negotiation
No RC4
No suite negotiation
PrecisionAccess defeats all recent attacks on SSL/TLS
by both Unauthorized and Authorized users
28
Single Packet Authorization (SPA)
• SPA = UID, CTR, OTP, GMAC
• History:
Each client has a UID, Seed, CTR, and EK
Invented >10 years ago
Commonly used for super user ssh access to servers
Mitigates attacks by unauthorized users
• SPA in the Software Defined Perimeter Spec
Based on RFC 4226, "HOTP”
HMAC-based One-Time Password
Used for hardware/software one time password tokens
UID = Universal ID of SDP Client
CTR = hashed with seed to create OTP
OTP = One-Time Password
GMAC = signature of UID, CTR, and OTP for data authentication
Seed = shared secret for OTP
EK = shared key for GMAC AES-256
OTP = HMAC[seed || CTR]
GMAC = EK [UID || OTP || CTR]
UID, OTP, CTR, & GMAC are sent as clear text.
Counter is increment to mitigate playback attacks
SPA occurs before TLS (SSL) connection
Mitigates DoS & other TLS attacks by unauthorized users
• Highly efficient rejection
Defeats DoS & other attacks on SSL
32-bit
64-bit
32-bit
128-bit
UID
Counter
OTP
GMAC
29
SDP Device Authentication
mutual TLS
30
Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• EC:
• AES256-GCM:
Elliptic Curve cryptography
Smaller keys / faster math than RSA cryptography
• DHE:
Diffie-Hellman key exchange algorithm
Generates the pre-master keys of GCM
Ephemeral keys per session for Perfect Forward Secrecy
But not client or server authentication
• RSA:
Public/private key pair with an X.509 certificate
Client and server authentication
Vidder’s implementation:
Certificates “pinned” to a trusted root certificate
Advanced Encryption Standard (NIST FIPS 197)
Symmetric key encryption
256-bit key, 128-bit cipher block size
Galois/Counter Mode
Encryption with simultaneously data authentication
PC’s and servers implement GCM in hardware
Negligible performance impact
• SHA384:
Secure Hash Algorithm (member of SHA-2)
Generates a 384 bit hash
Key Derivation Function (KDF) for generating keys from master
Not the hundreds of (possibly compromised) roots browsers trust
Employs OCSP stapling (RFC 6066)
Forwards the OCSP response with TLS Server hello
Reduces the load on the OCSP responder
Mitigates a DoS attack of the OCSP responder
Mutual TLS
Authentication of the client to server & server to client
31
SDP Device Authentication
mutual TLS Handshake Deep Dive for:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
32
Controller’s PKI Certificate Authority (CA) Initialization
Root Cert
Root Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Vidder
issuer:
Vidder
Hash
Vidder Public
---------------Signature
CRL
CA
OCSP
PA
33
Controller Initialization
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer:
Vidder
Hash
Ctrl Public
---------------Signature
CRL
CA
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
OCSP
PA
34
Mutual TLS: Client Initialization
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer:
Vidder
Hash
Client Public
---------------Signature
CRL
CA
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
OCSP
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
Private key put in Certificate Store as Non-Exportable
35
Mutual TLS: Client Hello
Root Cert
CRL
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
CA
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
OCSP
Client Hello
Highest SSL version,
Ciphers supported,
Session Id = 0,
Client RND
OCSP status
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
36
Mutual TLS: Server Hello
Root Cert
OCSP Response
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
CRL
Server Hello
Selected SSL version,
Selected Cipher,
Session Id = RND,
Server RND
Good
CA
Certificate request
(Vidder root only)
Server Done
OCSP
Server Key Exchange
βG
--------------Signature
Cr,
Sr, βG
Hash
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
Serial
#
issuer:
Vidder
Ctrl Public
---------------Signature
Serial #
Validity
Time
Hash
Good
---------------Signature
Random starting point “β”
Calculate βG
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
37
Mutual TLS: Client Verifies Server Cert
Root Cert
Valid cert chain
Not expired
Not revoked
Controller’s cert is trusted !!!
βG
Equal ?
Controller Cert
Root Cert
Controller Cert
Serial #
Hash
Validity
Time
Good
---------------Signature
Original
Hash
subj: Ctrl
issuer:
Vidder
Hash
Ctrl Public
---------------Signature
Original
Hash
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
Server Key Exchange
βG
--------------Signature
Cr,Hash
Sr, βG
Equal ?
CA
OCSP Response
Certificate request
(Vidder root only)
Server Done
Cr,Hash
Sr, βG
CRL
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
Equal ?
OCSP
Server Hello
Selected SSL version,
Selected Cipher,
Session Id = RND,
Server RND
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
38
Mutual TLS: Client Key, Client Cert, Verify Client
OCSP Response
Client Cert
Equal ?
Valid cert chain
Not expired
Not revoked
Client’s cert is trusted !!!
Client is trusted !!!
αG
subj: Client
issuer:
Vidder
Hash
Serial
#
Client Public
---------------Signature
Original
Hash
CRL
Good
CA
OCSP
OCSP Response
Equal ?
Random starting point “α”
Calculate αG
Serial #
Validity
Hash
Time
Good
---------------Signature
Original
Hash
Serial #
Validity
Time
Hash
Good
---------------Signature
Certificate Verify
Signature
Hash
Hash
All text
Equal ?
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
Certificate Verify
All text
Signature
Hash
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
39
Mutual TLS: Calculate Final ECDH Key, Derive Session Keys
CRL
Find point ECDH on the elliptic curve
Premaster key (Kpm) = x coord of ECDH
Master Key (Km) = PRF(Kpm, "master secret", Cr, Sr)
Iterate PRF(Km, "key expansion", Sr, Cr) for AES keys:
Client Key, Server Key,
Client IV, Server IV
Created α
Received βG
ECDH = α(βG)
Created β
Received αG
ECDH = β(αG)
CA
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
OCSP
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
40
Mutual TLS: Client Change Cipher Spec, Server Integrity Check
Client Cert
subj: Client
issuer: Vidder
Client Public
---------------Signature
CRL
CA
OCSP
Certificate Verify
Signature
Hash
Hash
All text
Equal ?
Change
Cypher Spec
Root Cert
Controller Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
Certificate Verify
All text
Signature
Hash
PA
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
41
Mutual TLS: Server Change Cipher Spec, Client Integrity Check
Client Cert
subj: Client
issuer: Vidder
Client Public Change
---------------Cypher Spec
Signature
CRL
CA
OCSP
Certificate Verify
All text
Signature
Hash
Controller Cert
Root Cert
Controller Cert
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Ctrl
issuer: Vidder
Ctrl Public
---------------Signature
PA
Certificate Verify
Signature
Hash
All text
Hash
Equal ?
Root Cert
Client Cert
subj: Vidder
issuer: Vidder
Vidder Public
---------------Signature
subj: Client
issuer: Vidder
Client Public
---------------Signature
42