CS 255 – Cryptography & Computer Security

CS 255 – Cryptography & Computer Security Programming Project 2 – Winter 04 Priyank Patel pkpatel@cs.stanford.edu

Chat System so far… PT file Offline ChatAdmin Encrypt CT file Decrypt Handle/username Chat Server Chat Client Y/N Encrypted Session

New Setup PT file with privileges Offline ChatAdmin Encrypt CT file Decrypt Chat Client Online Certificate Authority Password authenticate client and issue certificate 1- way authenticated SSL Session 2- way authenticated SSL Session Chat Server • Determine privileges from certificate • Admit to the appropriate room Room A Room B

Requirements • Secure all traffic using SSL • Use X509 certificates for authentication • Use password authentication only to procure certificates • Use X509 V3 extensions to provide access control • Implement a secure and efficient online certificate revocation system (extra-credit)

Offline PKI Setup • keytool– command line utility • organizes key material into keystores • one keystore file for each entity • initially keystore contains the public/private key pair and a self-signed certificate • allows storage of trusted certificate entries and trusted certificate chains

Offline PKI Setup (contd..) • Generate keystore for the RootCA (verigoodsign, inc.) keytool -genkey –alias mykey -keystore RootCA [asks a bunch of information …] [similar for every other entity] Keystores • RootCA • mykey • ChatServer • mykey • Client_1 • mykey ...

Offline PKI Setup (contd..) • Everybody trusts the RootCA (verigoodsign) keytool -export -alias mykey -file RootCA.cer -keystore RootCA [dumps the RootCA’s self-signed certificate to disk] keytool -import -trustcacerts -alias rootca -file RegCA.cer -keystore ChatServer [similar for every other entity] Keystores • RootCA • mykey • ChatServer • mykey • rootca • Client_1 • mykey • rootca ...

Offline PKI Setup (contd..) • ChatServer public key signed by the RootCA (create the class KeySigner) • Create a new certificate for the ChatServer’s public key, signed by the RootCA’s private key (Chat.X509CertificateGenerator) • Replace self-signed cert in “ChatServer” KS with a certificate signed by the RootCA. • java.security.KeyStoreallows you to load a keystore from a file and manipulate entries in it. • ChatServer • mykey • rootca • ChatServer • mykey (signed by RootCA) • rootca

SSL – Secure Socket Layer • Provides authentication (optional), handshaking and encryption and integrity. • Normally, server authenticates to the client, but the client does not as part of the SSL setup(unless explicitly required by the server) • Once handshake has been done, symmetric encryption is used for the rest of the session. • SSL setup requires 2 steps (roughly speaking) : • Trust establishment • Key Generation

SSL – JSSE API

SSL – JSSE API • javax.net.SSLContext – encapsulates the information required for setting up a connection • javax.net.SSL.KeyManager • Obtained from the KeyManagerFactory • Initialized with the KeyStore and KeyStore password • javax.net.SSL.TrustManager • Obtained from the TrustManagerFactory • Initialized with the KeyStore [does not require the password – because does not require to use the private key of the keystore]

SSL – JSSE API • Client sockets : javax.net.ssl.SSLSocket • Useful way to create sockets on the client: • SSLSocketFactory.createSocket(host, port); • SSLSocketFactory created from SSLContext • [this call actually connects to the server running on “host” and listening on port number “port”] • SSLSocket object also returned on a server when a remote client connects.

SSL – JSSE API • Server sockets :javax.net.ssl.SSLServerSocket • Useful way to create sockets on the server: • SSLServerSocketFactory. createSocket(port); • SSLServerSocketFactorycreated fromSSLContext • Socket created in this manner is bound to the “port”. • Client authentication required or not SSLServerSocket.setNeedClientAuth(true/false)

SSL – JSSE API • Server :SSLServerSocket.accept() • Returns SSLSocket object on connection from client. • No SSL handshake, authentication yet. • SSLSock.handshake() : perform actual SSL handshake • throws Exception on failure • can be one of several exceptions • CertificateExpiredException, CertificateParsingexception, etc.

SSL – JSSE API • After successful handshake, use like normal sockets. • Get a BufferedReader and Writer and start exchanging messages. • Every message using the socket’s I/O objects will be encrypted and checked for integrity by the underlying library

Certificate Extensions • Customized v3 extensions • RoomAExtension and RoomBExtension • Are true/false based on the privileges in the initial file • Make sense only for the client certificates • Client can have access to either room A or room B • Rejected if {true,true} or {false,false}

Certificate Extensions • Where in the system do you check for valid privileges? • At the time when the client handshakes with the server. • A question of trust? => modification required in the TrustManager • Extend the TrustManager to MyTrustManager (MTM) • Use MTM with your SSLContext on the server.

Certificate Extensions (contd..) • MyTrustManager class • Override checkClientTrusted(…) • Check if the client certificate has the invalid privileges [i.e. allowed in both rooms or none] • If failure, throw CertificateException • MTM will be called by the system during the SSL handshake.

Certificate Revocation • Need to add checks on the ChatServer and the CertificateAuthority. • Space-efficient.

Finally… • Document succinctly but comprehensively. (without aiming for the Pulitzer prize!) • Best of luck…

CS 255 – Cryptography & Computer Security