SSL and Millicent Protocols
Presented by: Shivnarayan Rajappa (A2305213004) Soorya M (A2305213014) Siddhant Bansal (A2305213034) Sachin Kaja (A2305213510) Siddharth Singh (A2305213513) Rohan Sampson (A2305213519)
INTRODUCTION
SSL (Secure Sockets Layer) is an encryption protocol which is used to secure the transmission of sensitive information over the Internet. It was developed by Netscape and was in version 3.0 when a new protocol TLS (Transport Layer Security) was introduced – as a new version of SSL. TLS 1.0 was comparable to SSL 3.0 but TLS 1.1 and 1.2 have significant improvements over SSL. Both terms SSL and TLS are used interchangeably today. SSL is built over the TCP/IP layer so that other protocols like HTTPS on the higher levels are unaffected.
While performing sensitive tasks on the Internet, such as bank transactions or confidential work, we need some form of encryption so that the information may not be accessed by a third party. SSL enables this by allowing the purchase of SSL Certificates from a Certified Authority (CA). CAs like DigiCert let people purchase an SSL certificate for their sites. They run a background check and assign the domain a certificate which proves that they are trustworthy. Since the browser trusts the CA, and the CA trusts the website – a trustworthy connection may be established between the user and the server.
SSL works using both asymmetric and symmetric encryption schemes. There is a handshaking process which allows a secure connection to be established between the client and the server. Symmetric encryption uses the
same key to encrypt and decrypt the data. It is very fast and efficient, but if the key is lost or a third party obtains it, then the information is at risk. Asymmetric encryption uses 2 different keys for encryption and decryption – a public key and a private key. Anything encrypted with the public key can only be decrypted by the private key, and vice versa. This form of encryption is very costly (1000 times costlier than symmetric) but provides significantly more protection from third party attacks.
WORKING OF SSL/TLS PROTOCOL
SSL is divided into four layers – Record Layer, ChangeCipherSpec Protocol, Alert Protocol and Handshake protocol.
Record Layer: The record layer formats the Alert, ChangeCipherSpec, Handshake and application protocol messages. This formatting provides a header for each message. The fields that comprise the five-byte header of the Record Layer are: Protocol Definition (1 byte), Protocol Version (2 bytes) and Length (2 bytes). The protocol messages that follow the header cannot be longer than 16,384 bytes, as specified by the SSL protocol. It provides the facilities like confidentiality through encryption and integrity check using MAC. MAC information is very much necessary in this layer, as it checks the integrity of the record. This is nothing but, a hash value. MAC value is the hash value calculated from sequence number, padding, primary data, and secret key. So now the whole data along with the MAC is encrypted with a symmetric key and this whole encrypted data along with the Header form complete record, ready for transmission over TCP.
ChangeCipherSpec Protocol: The ChangeCipherSpec layer is composed of one message that signals the beginning of secure communications between the client and server. Though the ChangeCipherSpec Protocol uses the Record Layer format, the actual ChangeCipherSpec message is only one byte long, and signals the change in communications protocol by having a value of ‘1’.
Alert Protocol:
This protocol sends errors, problems or warnings about the connection between the two parties. This layer is formed with two fields: the Severity Level and Alert Description. Severity Level: The Severity Level sends messages with a ‘1’ or ‘2’ value, depending on the level of concern. A message with a value of ‘1’ is a cautionary or warning message, suggesting that the parties discontinue their session and reconnect using a new handshake. A message with a value of ‘2’ is a fatal alert message, and requires that the parties discontinue their session. Alert Description: The Alert Description field indicates the specific error that caused the Alert Message to be sent from a party. The alert descriptions can be any of the followingCloseNotify, UnexpectedMessage, BadRecordMAC, DecompressionFailure, HandshakeFailure, NoCertificate, BadCertificate, UnsupportedCertificate, CertificateRevoked, CertificateExpired, CertificateUnknown, IllegalParameter.
Handshake Protocol: Shiv’s Text
The next stage of handshake involves authentication and key exchange between both parties. 1. Server's authentication: o server's certificate or server's public key o certificate request o "hello done" notification 2. Client's authentication: o client's certificate or client's public key o certificate verification Authentication and key exchange are both done by sending certificates, as long as both sides can provide them. Using all the data transferred between the
client and the server, the client will generate a premaster secret. It will use the server’s public key to encrypt a premaster secret and send it to the server.
If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own digital certificate to the server along with the encrypted premaster secret. If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps which the The premaster secret is used to generate a master secret which in turn will be used to generate symmetric keys for data exchange. Both the client and the server use the master secret to generate session keys which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity. Depending on if there were certificates send, and depending on the type of these certificates, both sides may be able to verify each other's identity by checking the validity of these certificates. This validity check is the only part of SSL which may fail without SSL aborting the connection immediately. The handshake's final stage. 3. server's finish: o change cipher spec o "finished" notification 4. client's finish: o change cipher spec o "finished" notification
The client informs the server that future messages from the client will be encrypted with the session key. It then sends a separate encrypted message indicating that the client portion of the handshake is finished. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate encrypted message indicating that the server portion of the handshake is finished.
The change cipher spec message is simply a byte with value 1 which tells the other side to set up the cipher suite agreed on in the first stage (one for data encryption and one for subsequent key exchanges). The notification at the end marks the completion of the handshake. It is already encrypted using the agreed-on algorithms, and it contains a message authentication code derived from the preceding handshake.
Advantages Authentication In addition to encryption, a proper SSL certificate also provides authentication. This means you can be sure that you are sending information to the right server and not to a criminal’s server. Any of the computers could pretend to be your
website and trick your users into sending them personal information. It is only possible to avoid this by using a proper Public Key Infrastructure (PKI), and getting an SSL Certificate from a trusted SSL provider.
Confidentiality When the connection is established between the client and server, they both transfer their messages through encryption which can only be decrypted using the keys they have. This helps in keeping the data sent over by the client to be only accessed by the server and hence prevents attacks such as man in middle, phishing, spoofing. It also helps in e-commerce websites and to gain trust of the customers.
Protects from phishing A phishing email is an email sent by a criminal who tries to impersonate your website. The email usually includes a link to their own website or uses a manin-the-middle attack to use your own domain name. Because it is very difficult for these criminals to receive a proper SSL certificate, they won’t be able to perfectly impersonate your site.
Shiv’s Text
Millicent Protocol A secure Internet payment system is required that is cost-effective and convenient for the purchase of low-priced services and access to electronic resources at prices in the range 0.1–100 cents, for example to charge users for web page access, email transmissions or Internet phone calls. Most existing
payment schemes such as credit card transactions are too expensive for these purposes. Here we describe the solution offered by the Millicent scheme. The scheme employs the simple form of secret-key-based digital signature to reduce its computational cost. Encryption is used only where privacy is required.E The authors of the Millicent protocol have summarized the drawbacks of the payment methods currently available as follows. All of them will require cryptographic security, their computing and communication costs vary, but they are significant in all cases.E
The Millicent scheme: The Millicent project has developed a scheme for the secure distribution and use of scrip – a specialized form of digital cash that is designed for use in low-value transactions. Millicent is of interest here because it employs several of the security techniques described in this chapter with an outcome that is quite different from those of SSL and other security systems. Scrip is a form of digital cash that is valid only for a specific vendor. It is designed to offer the following features:
• it has value only at a specific vendor • it can be specounterfeite • it is tamper-resistant and hard to counterfeit • it can be spent only by its rightful owner • it can be produced and validated efficiently
The design of the Millicent scheme is scalable because each vendor’s server is responsible only for validating the scrip that it has issued. Customers can acquire scrip directly from the vendor, or from a broker who holds scrip for many vendors, by performing a conventional transaction. Scrip, the vendor-specific currency introduced by Millicent, is represented by digital tokens with the following format:
The properties field is available for uses determined by the vendor – it might for example include the customer’s country or state of residence, so that the appropriate tax rate can be applied. The certificate is a digital signature protecting all the fields in the scrip against modification. The signature is produced by the MAC method described in Section 7.4.2. The purpose of the remaining fields will emerge in the following description. Scrip is generated and distributed by Brokers – brokers are servers that deal in scrip in bulk, relieving customers and vendors of some of the overheads involved. Brokers exchange scrip for real cash, buying scrip (or the right to generate scrip) from vendors at a discount and selling scrip to customers against credit card or other payments. Customers may buy scrip for several vendors from a single broker, aggregating the charges and paying at the end of a period. Millicent was designed as an electronic cash system that avoids the communication overheads and the delays associated with a centralized system, while providing security adequate to prevent fraudulent use. The security of scrip is based on digital signatures; encryption is used for secrecy where necessary. Low-cost cryptography is used because there is no point in making the cost of breaking the security of the system greater than the value of the transactions for which it is used. The Millicent scheme is free-standing. It can be implemented without support from other services, such as a secure name service, because it does not depend upon an externally authenticated identity for customers or vendors. Instead, Millicent generates and distributes unique secret keys for use by the parties to scrip transactions.
Scrip: Scrip has the following fields : Vendor identifies the vendor for the scrip. Value gives the value of the scrip.
ID# is the unique identifier of the scrip. Some portion of it is used to select the master_scrip_secret used for the certificate. Cust_ID# is used to produce the customer secret. A portion of Cust_ID# is used to select the master_customer_secret which is also used in producing the customer secret. Expires is the expiration time for the scrip. Props are extra data describing customer properties (age, state of residence, etc.) to the vendor. Certificate is the signature of the scrip.
The certificate of a piece of scrip is generated by hashing the body of the scrip with a secret. The secret is selected using a portion of the scrip's ID#. This is used to check if the scrip’s value has been tampered with or not or in other words, this is used to check the validity of the scrip.
The certificate is recomputed and checked against the certificate sent with the scrip. If the scrip has been tampered with, then the two certificates will not match. Second, there is a unique identifier (ID#) included in the scrip body and the vendor can check for double spending by seeing if it has recorded that identifier as already spent. Generating and validating scrip each require a little text manipulation and one hash operation. Unless the secret is known, scrip cannot be counterfeited or altered.
Millicent Protocols Scrip in the clear In the simplest possible Millicent protocol, the customer just sends an unspent piece of scrip in the clear (i.e., not encrypted or protected in any way) along with each request to the vendor. The vendor returns the desired result along with a new piece of scrip (also in the clear) as change. This protocol offers almost no security: an eavesdropping third party can intercept the scrip being returned as change and use it himself. When the rightful owner later attempted to spend the scrip, the vendor would have a record of it being previously spent, and would refuse the request.
Private and secure
To add security and privacy to the Millicent protocol, we establish a shared secret between the two parties and then use the secret to set up a secure communications channel using an efficient, symmetric encryption method. In Millicent, scrip can be used to establish this shared key. When a customer buys an initial piece of scrip for a vendor, a secret is generated based on the customer identifier, and returned securely with the scrip. This requires either that the transaction be performed using some secure non-Millicent protocol, or that the scrip be purchased using a secure Millicent transaction. The vendor does not directly record the secret associated with the piece of scrip. Instead, the customer identifier (Cust_ID#) field of the scrip allows rapid recalculation of the secret. The customer identifier must be unique whenever scrip is transmitted to a new customer, but it need not have any connection to the identity of the customer. When the vendor receives the request, he derives the customer secret from the customer identifier in the scrip, derives the message key from the customer secret, and uses the message key to decrypt the request. The change scrip can be returned in the clear, while the response and any new secrets are returned to the customer encrypted by the message key.
Secure without encryption
As in the previous protocol, the customer securely gets an initial piece of scrip and customer secret. To make a purchase, the customer sends the request, scrip, and a "signature" of the request to the vendor. The signature is produced in the same way that the certificate of the scrip is produced. The scrip and request are concatenated with the customer secret. The customer runs an efficient cryptographic one-way hash function over this string and sends the resulting hash as the signature. When the vendor receives the request, he derives the customer secret from the scrip and regenerates the signature for the request. If the scrip or request have been tampered with in any way, the signature will not match.
