Security

Asymmetric Cryptosystems

• Need a hard problem (like symmetric cryptosystems)

• With a trap door: if you know a secret, the hard problem becomes easy

One-Way Functions• Easy to compute, hard to invert

• Trap-door one way function:– D (E (M)) = M– E and D are easy to compute.– Revealing E doesn’t reveal an easy way to

compute D.– Hence, anyone who knows E can encrypt, but

only someone who knows D can decrypt

Cryptography

• Cryptography makes it difficult for an unauthorized third party to access and understand private communication between two parties. Private data can be made unintelligible to unauthorized parties through the process of encryption. Encryption uses complex algorithms to convert the original message, or cleartext, to an encoded message, called ciphertext. Decryption does the reverse.

• A key is a bit string that is used by the algorithms for encryption or decryption.

Encryption Algorithms• Parties

– Alice and Bob want to communicate.– Charlie, the unauthorized third party, is known as the

attacker.

• Secret key– Alice and Bob agree on an algorithm, and have the same

secret key, which they use to encrypt plaintext and decrypt cyphertext.

– Well-known secret key cryptographic algorithms include the Data Encryption Standard (DES), triple-strength DES (3DES), Rivest Cipher 2 (RC2), Rivest Cipher 4 (RC4) and the Advanced Encryption Standard (AES).

Encryption Algorithms (cont.)

• Public key– Alice and Bob agree on an algorithm, and Alice creates a

pair of keys—public and private—and sends the public key to Bob and other people. Bob (or anyone else) encrypts with the public key, but only Alice can decrypt with the secret private key.

– Well-known public key algorithms include Rivest Shamir Adleman (RSA) and Diffie-Hellman (DH).

– Because they require extensive computations, these algorithms run slowly. Therefore they’re only used for encrypting small pieces of data, such as secret keys or signatures.

RSA [Rivest, Shamir, Adelman 78]One-way function:

multiplication is easy, factoring is hardTrap-door: number theory (Euler and Fermat)

Security of RSA• n is public, but not p and q where n = pq

• How much work is factoring n?

n ~200 digits – would take quintillions of years

Number Field Sieve (fastest known factoring algorithm) is:

O(e1.9223((ln (n))1/3 (ln (ln (n)))2/3)The movie Sneakers is about what happens if someone discovers a O(nk) factoring algorithm.

Math behind RSA

• Find P and Q, large prime numbers• Choose E such that E is greater than 1, E is

less than PQ, and E and (P-1)(Q-1) are relatively prime, which means they have no prime factors in common. E does not have to be prime, but it must be odd. (P-1)(Q-1) can't be prime because it's an even number.

• Compute D such that (DE - 1) is evenly divisible by (P-1)(Q-1). Mathematicians write this as DE = 1 (mod(P-1)(Q-1)), and they call D the multiplicative inverse of E. This is easy to do -- simply find an integer X which causes D = (X(P-1)(Q-1) + 1)/E to be an integer, then use that value of D.

• The encryption function is C=(T^E)mod PQ, where C is the ciphertext (a positive integer), T is the plaintext (a positive integer), and ^ indicates exponentiation. The message being encrypted, T, must be less than the modulus, PQ.

• The decryption function is T=(C^D)modPQ, where C is the ciphertext (a positive integer), T is the plaintext (a positive integer), and ^ indicates exponentiation.

• Your public key is the pair (PQ,E). Your private key is the number D (reveal it to no one). The product PQ is the modulus (often called N in the literature). E is the public exponent. D is the secret exponent.You can publish your public key freely, because there are no known easy methods of calculating D, P, or Q given only (PQ, E) (your public key). If P and Q are each 1024 bits long, the sun will burn out before the most powerful computers presently in existence can factor your modulus into P and Q.

Asymmetric Cryptosystems

• Encryption and Decryption are done with different keys

• Keep one of the keys secret, reveal the other

EKRA (EKUA (M)) = MAlice’s Public Key: KUA

Alice’s Private Key: KRA

Only KRA can decrypta message encryptedusing KUA.

Public-Key Applications: Privacy

• Alice encrypts message to Bob using Bob’s Private Key

• Only Bob knows Bob’s Private Key only Bob can decrypt message

Encrypt DecryptPlaintextCiphertext

Plaintext

Alice Bob

Bob’s Public Key Bob’s Private Key

Signatures

• Bob knows it was from Alice, since only Alice knows Alice’s Private Key

• Non-repudiation: Alice can’t deny signing message (except by claiming her key was stolen!)

• Integrity: Bob can’t change message (doesn’t know Alice’s Private Key)

Encrypt DecryptPlaintext

SignedMessage

Plaintext

AliceBob

Alice’s Private Key Alice’s Public Key

Encrypt DecryptPlaintext

Ciphertext

Plaintext

User Server

KUS KRS

The InternetThe Internet

Public Key Private Key

How does User know the public key to use?

Key Management

Approach 1: Meet Secretly

• User and Server Operator meet secretly and swap public keys– If you can do that, might as well agree on a

secret (symmetric key) instead– Doesn’t work for Internet transactions

Approach 2: Public Announcement

• Publish public keys in a public forum– Append to email messages– Post on web site– New York Time classifieds

• Easy for rogue to pretend to be someone else– Forge email, alter web site, lie to New York

Times

Approach 3: Public Directory• Trusted authority maintains directory

mapping names to public keys• Entities register public keys with

authority in some secure way• Authority publishes directory

– Print using watermarked paper, special fonts, etc.

– Allow secure electronic access• Depends on secure distribution of directory’s

key

Approach 4: Certificates

VeriSign

User Server

KUS

CS = EKRVeriSign[“Server”, KUS]

CS

Request

$$$$

EKUVeriSign (CS) = [“Server”, KUS] Knows KRS

• Two Kinds of SSL– Low Encryption (40-bit; 1.1x1012 possible keys)– High Encryption (128-bit; 3.8x1038 possible keys)

• SSL is a transport level technology for authentication and data encryption between a web server and a Web server (example).

• Applied at the socket interface from the application to the network software.

SSL Background

Plaintext Cipher Text

Data LinkHeader

InternetHeader

TransportHeader

ApplicationHeader Data being sent

SSL (Secure Sockets Layer)Browser Server

Hello

KRCA[Server Identity, KUS]

Check Certificate using KUCA

Pick random KKUS[K]

Find K using KRS

Secure channel using K

Note: This is slightly simplified from the actual SSL protocol. This versionis vulnerable to a person-in-the-middle attack!

Security Achieved by the Secure Sockets Layer (SSL)

• ConfidentialityEncrypt data being sent between client and server, so that

passive wiretappers cannot read sensitive data.

• Integrity ProtectionProtect against modification of messages by an active

wiretapper.

• AuthenticationVerify that a peer is who they claim to be. Servers are usually

authenticated, and clients may be authenticated if requested by servers.

TCP/IP Protocol Stack With SSL

TCP/IP Layer Protocol

Application Layer HTTP, IMAP, NNTP, Telnet, FTP, etc.

Secure Sockets Layer

SSL

Transport Layer TCP

Internet Layer IP

Secure sockets layer

• Developed by Netscape, now taken on by Internet Engineering Task Force, to establish Transport Layer Security (TLS 1.0 is just SSL 3.1)

• Works by securing communication channels• Provides server authentication, confidentiality,

integrity (SSL 3.0 supports client authentication too)• Lower-level than HTTP, FTP etc• Higher-level than TCP/IP

Benefits of SSL

• Used by most browsers• Simple to use service such as HTTPS built on

top of SSL• Designed to be easy for clients

– Server authentication always required– Usually, no client authentication required

How it works

• Client – connects to site using HTTPS protocol and tells server which

cipher suites it supports

• Server – tells client which cipher suites it supports– sends certificate to client– Initiates a key exchange algorithm using public key cryptography

• Client– Completes key exchange by generating symmetric key which is

sent back to server. This key used for subsequent data exchange.

– Verifies certificate (ie checks for trusted CA)– Tells server which cipher suite to use

How SSL Achieves Authentication

• Optional• Protocol

– If the client wants to authenticate the server then they follow the protocol in “Authentication with a Public Key Certificate” with the client acting as Bob.

– If the server wants to authenticate the client then they follow the protocol in “Authentication with a Public Key Certificate” with the server acting as Bob.

How SSL Works

1.Handshake– a negotiation process that creates or

rejoins a session

2.If (Handshake succeeds) then Encrypted data can be exchanged

ElseThe connection is aborted

How SSL Works: the Handshake

• Negotiate the cipher suite

• Authenticate identities (optional)

• Exchange secret key

How SSL Works: Negotiate the Cipher Suite

• A cipher suite – A set of cryptographic algorithms

• An algorithm for exchanging a secret key • A secret key encryption algorithm and key

length• A cryptographic hash function

• The client tells the server which cipher suites it has available, and the server chooses the best mutually acceptable cipher suite.

How SSL Achieves Confidentiality

• Create a secret key– Based on information generated by the client with a secure

random number generator

• Use public keys to exchange the secret key– The server sends its public key to the client– The client encrypts the secret key with the server's public

key and sends it to the server– The server decrypts the secret key information with the

server’s private key

• Encrypt and decrypt data with the secret key– The client and server use the negotiated algorithm

Cryptographic Hash Functions

Q: How can we prevent Charlie from tampering with data that Alice sends to Bob?

A: Make any change in the data detectable.

• A cryptographic hash function is like a checksum. – A cryptographic hash function generates, a small string of

bits, known as a hash, from a message. Any slight change to the message should make a change in the resulting hash.

– Widely used hash functions are Message Digest 5 (MD5) and Secure Hash Algorithm (SHA).

Message Authentication Code

• A message authentication code (MAC) is like a cryptographic hash, but it uses a secret key.

• Including a secret key with the data processed by a cryptographic hash produces a hash called an HMAC.

• Here’s how we prevent Charlie from tampering with data that Alice sends to Bob.– Alice calculates an HMAC for her message and append the

HMAC to her original message. She encrypts the message plus the HMAC using a secret key she shares with Bob.

– Bob decrypts the message and recalculates the HMAC. If his HMAC differs from the one Alice sent then the message was modified in transit.

How SSL AchievesIntegrity Protection

• Client and server use their secret key, and an agreed-upon cryptographic hash function to attach an HMAC to each message sent.

• The receiver checks that each message has not been altered.

Digital Signatures

Q: How does Alice prove to Bob that a message comes from her?

A: Demonstrate that she has her private key.

• Protocol– As before, Alice creates her public and private keys, and

distributes her public key with her name attached.– Alice encrypts a message using her private key and sends

the message to Bob.– If Bob can decrypt the data with Alice's public key, the

message must have been encrypted by Alice with her private key, since only Alice has her private key.

– This is called a digital signature.

Public Keys and Authentication

Q: How does Alice prove to Bob that she is Alice?

A: Demonstrate that she has her private key.

• Protocol– Bob creates a random number, encrypts it

with Alice’s public key and sends it to Alice.– Alice decrypts the random number with her

private key, and sends the random number to Bob, proving she’s Alice.

Public Keys and Authentication (cont.)

Q: How do we prevent Charlie from pretending to be Alice by circulating a public key named ‘Alice’?

A: By having someone we trust verify that Alice is Alice.

• Public Key Certificate– A digital ‘passport’ that is issued by a trusted organization

and identifies the bearer.– A trusted organization is called a certificate authority (CA).– The CA digitally signs the certificate, thereby attesting to the

validity of the certificate’s information.

Public Key Certificate

Contains the fields: • Subject’s public key• Subject

– Information about the entity that the certificate represents.

• Issuer– The CA that issued the certificate. If a user trusts the CA that

issues a certificate, and if the certificate is valid, the user can trust the certificate.

• Signature– The signature is created using the CA's private key and ensures the

validity of the certificate.

• Period of validity– The certificate’s expiration date.

Authentication with a Public Key Certificate

Q: How is a public key certificate used to help Alice prove to Bob that she is Alice?

• Protocol– Bob obtains Alice’s public key certificate.– Bob also has a certificate for a trusted CA that supposedly

signed Alice’s public key certificate.– Bob checks that the trusted CA signed Alice’s public key

certificate by using the CA’s public key to decrypt the signature in Alice’s public key certificate.

– Run the protocol for “Q: How does Alice prove to Bob that she is Alice?”

Certificate Chains

• Multiple certificates may be linked in a certificate chain. – The first certificate is that of the sender. – The next is the certificate of the entity that issued the

sender’s certificate.– If there are more certificates in the chain, each is that of the

authority that signed the previous certificate. – The final certificate in the chain is the certificate for a root

CA, a certificate authority that is widely trusted.– Well-known public CAs include VeriSign, Entrust, and GTE

CyberTrust.

How SSL Works: the Handshake in Detail

How SSL Works: the Handshake in Detail

1. Client hello - The client sends the server information including the highest version of SSL it supports and a list of the cipher suites it supports.

2. Server hello - The server chooses the highest version of SSL and the best cipher suite that both the client and server support and sends this information to the client.

3. Certificate - If server authentication is required then the server sends the client a certificate or a certificate chain.

4. Certificate request - If the server needs to authenticate the client, it sends the client a certificate request.

5. Server key exchange - The server sends the client a server key exchange message when the public key information sent in 3) above is not sufficient for key exchange.

6. Server hello done - The server tells the client it is finished with its initial negotiation messages.

How SSL Works: the Handshake in Detail

7. Certificate - If the server requests a certificate from the client in Message 4, the client sends its certificate chain, like the server did in Message 3.

8. Client key exchange - The client generates information used to create a key to use for symmetric encryption. For RSA, the client then encrypts this key information with the server's public key and sends it to the server.

9. Certificate verify – If the server is authenticating the client, the client sends a random number that it digitally signs. When the server decrypts number with the client's public key, the server authenticates the client.

10. Change cipher spec - The client tells the server to change to encrypted mode. 11. Finished - The client sends the server a hash of the handshake messages.12. Change cipher spec - The server tells the client to change to encrypted mode.13. Finished - The server sends the client a hash of the handshake messages. • Encrypted data - The client and the server communicate using the symmetric

encryption algorithm and the cryptographic hash function negotiated in Messages 1 and 2, using the secret key that the client sent to the server in Message 8.

How SSL Works: the Handshake Shortcut

If the parameters generated during an SSL handshake are saved, these parameters can be re-used for future SSL connections.

• SessionDescribes an ongoing relationship between a

particular client and a particular serverOne session per SSL connectionBut a session may be reused repeatedly, on

sequential or concurrent connectionsReusing a session greatly speeds up handshaking

Issues with SSL

• Secures communication at the transport level rather than at the message level

• Does nothing to protect data sitting in a filestore or database

• Doesn’t support end-to-end security over a chain of entities

• Slows down processing by > 90%

SSL in Java

• Simpler to use HTTPS directly, but …• … can use Java Secure Sockets Extension

(JSSE)• Often no more than using SSLServerSocketFactory instead of ServerSocketFactory and SSLSocketFactory instead of SocketFactory

What can go wrong?• Java API doesn’t call right SecurityManager

checks (63 calls in java.*)– Font loading bug, synchronization

• ClassLoader is tricked into loading external class as internal

• Bug in Bytecode Verifier can be exploited to circumvent SecurityManager

• Policy is too weak and allows damaging behavior

Hostile Applets

• See http://java.sun.com/sfaq/chronology.html (about 1 new vulnerability/month)

• Easy to write “annoying” applets (policy is too imprecise; no way to constrain many resource operations)

• http://www.cigital.com/hostile-applets/index.html

Where

• java.security:– message digests– certificates

• Java Cryptography Extension (JCE)– Encryption– Key generation and agreement– Message authentication codes

• Java Secure Sockets Extensions (JSSE)– Implements SSL programmatically

Security provider architecture

• Java security consists of engines and algorithms• An engine is an operation that a programmer can

perform eg create a message digest• An algorithm is a particular implementation of that

operation eg MD5 or SHA for message digests• The security provider interface provides an easy

mechanism for substituting algorithms while leaving the basic operations unchanged

• Format:– engine.algorithm

eg MessageDigest.SHA

Security provider architecture

Java support for cryptography• Keys• Certificates• Key management• Message digests• Secure message digests• Digital signatures• Encryption & decryption

Keys & certificates: recap

• Two kinds of keys: – secret (symmetric)– public/private (asymmetric)

• Certificates can be used to authenticate public keys:– Public keys usually transmitted as part of a

certificate

Issues

• Key management and storage

• Self-certification?

• Hierarchy of trust

The Key class hierarchies: a partial view

java.security.Key

PublicKey PrivateKey

java.security.interfaces.DSAKey

DSAPrivateKeyDSAPublicKey

RSAPrivateKey

RSAPrivateKeyCrt

RSAPublicKey

java.security.KeyPair

java.crypto.SecretKey

Why so many?

• Certain algorithms require methods to access key generation parameters for export– DSAKey: methods getP(), getQ(), getG()

• Certain algorithms have specific roles– DHKey: Diffie-Hellman key exchange

Example: generate/export key pair

Source: Oaks (2001)

Example: import key pair

Source: Oaks (2001)

Distributing public keys: certificates

• Recall that a key doesn’t provide any authentication of the owner

• A digitally-signed document + public key doesn’t guarantee that the document came from X

• Certificates solve the problem. A Certificate Authority verifies the public key

• However, anyone can obtain a basic level certificate• Bootstrapping problem? Who verifies the certificate

containing the public key of the CA?• Workable solution: provide public keys of main CAs

(eg in browser or in Java implementation)

Certificates in Java

• java.security.cert.Certificate

byte[] getEncoded()void verify(PublicKey pk)publicKey getPublicKey()

• java.security.cert.CertificateFactory

Certificate generateCertificate(InputStream is)

• NB Imports a certificate (doesn’t generate from scratch)

Certificates in Java

Derived from: Oaks (2001)

Revoked certificates

• Expiration date is sometimes not sufficient

• For immediate invalidation, need a Certificate Revocation List (CRL)

• Not clear yet how CA issues CRL yet

• Support in Certificate class

Key & certificate management

• keystore: file (or may be database) holding keys and certificates

• Alias: keystore-specific name for entity eg mpc

• Distinguished name (DN): longer name for entity (but not guaranteed unique)– Usually includes common name (eg Martin

Cooke); organisation; location; state; country

• Manipulated using keytool or programmatically

keytool

Secret key management

• Recall that in public key systems, the private key must be kept private, but that in secret key systems, the secret key must be shared

• Management problem!– Use non-electronic means to distribute– Use public key encryption to send encrypted key

(eg SSL)– Use key agreement algorithm

• keytool doesn’t understand secret keys

http://java.sun.com/developer/technicalArticles/Security/Signed/

Message digestsupdate()

add data to digest

digest()

compute digest

Derived from: Oaks (2001)

• Recall that to verify a message digest, must read in message and its digest, compute the digest, and compare the two

– isEqual()

Source: Oaks (2001)

MAC

Derived from: Oaks (2001)

Digital signature example: sending

Derived from: Oaks (2001)

Digital signature example: receiving

Derived from: Oaks (2001)

Application: signed classes

• Recall entries in policy file of form:

grant signedBy “mpc” codebase “http://mpc.com” {java.io.FilePermission “-”, “read,write” ;

}

• Achieved via jarsigner tool– jarsigner app.jar mpc

Example: encryption

Derived from: Oaks (2001)