CS 255 – Cryptography & Computer Security Programming Project 2 – Winter 04 Priyank Patel

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

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

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] RootCA mykey... ChatServer mykey Client_1 mykey Keystores

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] RootCA mykey... ChatServer mykey rootca Client_1 mykey rootca Keystores

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.KeyStore allows you to load a keystore from a file and manipulate entries in it. ChatServer mykey (signed by RootCA) rootca ChatServer mykey 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

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); SSLServerSocketFactory created from SSLContext 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…