8.3 Experiments and Analysis
9.1.2 Improving secure server performance by re-balancing SSL/TLS hand-
[60] focused on the adjusting the computational imbalance in the SSL handshake protocol. It introduced the idea of the Client Aided RSA (CA-Aided). The motivation of this idea was taken from the concept of Server AidedRSA [61] that aims at offloading the expensive RSA computation from weak devices (such as smart cards) to powerful but un-trusted server [60].
In the technique of re-balancing the SSL handshake, the server sends the vector of elements and requests the client to perform some operation. The result of this operation is used by the server to decrypt thepre-master secret that is sent by the client. A care has been taken so that an attacker cannot derive the private key of the server from the vector that is sent by the server. An overview of the operations performed to re-balance the SSL handshake are described below.
• Theclient hello and theserver hello are the same as in the standard SSL hand- shake.
• The server’s certificate message includes the vector B = (b1, b2, ..., bk). The server’s
private exponentdcan be expressed as follows:
d= (a1∗b1+a2∗b2+...+akbk)modΦ(n) (9.1)
Where,
ai and bi are random vector elements of sizecbits and |n|bits respectively.
• The client encrypts the pre-master secret (a 48 bit number) with the server’s public key that is obtained from the server’s certificate to obtain the value y. This process is same as the standard SSL handshake. Here,yis the encryptedpre-master secret.
• The client uses the vectorBfrom the server’s certificate message and does the following operation to obtainz. This is an extra operation that the client needs to perform extra when compared to the standard SSL handshake.
9.1 Related Work 93
for 1≤i≤k
The vector Z such that, Z = (zi, z2, ..., zk) is sent to the server in the client key exchangemessage.
• The server is supposed recover the pre-master secret from the encrypted client key exchangemessage. Therefore, originally, the server needs to compute the xas follows:
xis nothing but the pre-master secret.
x=ydmod(n) (9.3) Where, d= (a1∗b1+a2∗b2+...+akbk) (9.4) Therefore, x=Yk i=1y aibimod(n) (9.5) Finally, x=Yk i=1zi aimod(n) (9.6)
• As shown in Equation 9.6, in the re-balanced SSL handshake, the server works less than that in the standard SSL handshake. The rest of the SSL handshake remains unchanged.
In this way, the server shifts a part of the heavy private key decryption operation at the client side.
Analysis
The server makes use of the CRT (Chinese remainder Theorem) to perform the exponentiation operation to decrypt pre-master secret message in the SSL handshake as described above. The details of the CRT are not described here for brevity. The confidentiality is appropriately maintained through the search space of 2c∗k. In this technique, the values of c and k are selected in such a way that the difficulty of exhausting the search space is equivalent to underlying RSA cryptosystem. The exhaustive search of 2c∗kvalues is equivalent to searching for all possible keys in a symmetric-key cryptosystem (E.g. DES, AES etc.) [60]. The well known study done by Verheul and Lenstra [62] gives the formulae to determine the equivalent key sizes that gives the same security as the keys sizes in asymmetric cryptosystem. [60] considers study [62] while deciding the 2c∗k search space1.
The CA-RSA achieves the speedup in the range of 11 for 1024 bit key and 19 for 2048 bit key at the server side processing. In addition, the client faces an additional computational overhead varying according to the RSA key sizes. The bandwidth requirement is increased since the client has to send the an extra bytes in client key exchange message. However, since SSL is purely CPU bounded [37], adding the small data in the handshake protocol messages does not affect the bandwidth requirement and hence the performance of SSL.
The CA-RSA enables the server to perform better by offloading some of the RSA de- cryption work to the client-side. This proposal makes the DoS attack expensive to produce because of two reason. The first one is due to the fact that the server can handle more SSL handshake simultaneously and the client or the attacker will have to work more. However, the attacker with adequate resource and computational power can still execute the DoS attack on the SSL server.
1More details about the scheme can be referred from [60], it is not explained here since it is out of the
An attacker can start initiating the SSL handshake with the server that uses CA-RSA, when the server requests for an extra computation (of calculating the vector Z as described in this section), the attacker can still send the bogus data. With this strategy the server will have to work considerably more than the client and hence DoS attack is still possible. Of course, the impact of DoS will be lesser than the DoS attack on the server that uses the traditional SSL handshake protocol. The difference in the impact can be anticipated by investing more resources (eg. bots) in the attack.