Server-aided Public Key Signatures for Diverse Network Devices

One of the main challenges of securing effective computation in diverse network devices tends to be a limitation of their computational power. Server assisted signature scheme was recently presented as nonrepudiation service for mobile and constrained devices. They all tend to have a feature in common: limited computational capabilities and equally limited power (as most operate on batteries). The scheme suffered with high storage requirements and memory requirements for the mobile clients. This makes them ill-suited for public key signatures. This paper examines practical and conceptual implications of using Server-Aided Signatures (SAS) for these devices. SAS is a signature method that relies on partially-trusted servers for generating (normally expensive) public key signatures for regular users. Although the primary goal is to aid small, resourcelimited devices in signature generation, SAS also fast certificate revocation, signature causality and with reliable timestamping.


Introduction
Digital signature schemes are among the most fundamental and useful inventions of modern cryptography. In such schemes, each user generates a (private) signing key and a (public) verification key. A user signs a message using his private signing key, and anyone can authenticate the signer and verify the message -using the signer's public verification key. A signature scheme is considered to be secure if signatures on new messages cannot be forged by any attacker who knows the user's public key, but not his private key. Computers and communication networks have become an integral part of many people's daily lives. Systems to facilitate commercial and other transactions have been built on top of large open computer networks. Two crucial features of digital signatures are non-repudiation and strong authentication of both origin and data. While digital signatures are rapidly becoming ubiquitous, one of the major recent trends in computing has been towards so-called smart devices, such as PDAs, cell phones and sensors. Although these devices come in many shapes and sizes and are used for a variety of purposes, they tend to have a feature in common: limited computational capabilities and equally limited power (as most operate on batteries). This makes them ill-suited for complex cryptographic computations such as large number arithmetic present in virtually all public key constructs. In fact, the computation power disparity between the smart devices and the adversary becomes even larger.
At the same time, increased use of digital signatures accentuates the need for effective revocation of cryptographic credentials and certificates, which has been an issue for a long time. However, now the problem is becoming more evident, e.g., the recent Verisign fiasco where a wrong certificate was issued (ostensibly to Microsoft) and its subsequent revocation were both slow and painful. Furthermore, current CRL-based revocation methods scale poorly and are not widely used in practice. Effective revocation is not only useful, but vital in some organizational settings (e.g., government and military) where digital signatures are used on important electronic documents and in accessing critical resources.
Consider a situation where a trusted user (Alice) does something that warrants immediate revocation of her security privileges. Alice might be fired, transferred or her private key has been compromised. Ideally (immediately following revocation) no one should be able to perform any cryptographic operations involving Alice's private key. In addition, when a cryptographic certificate is revoked (or simply expires), to establish the validity of digital signatures generated prior to revocation (or expiration) becomes a hard issue, due to the difficulty in determining the exact generation time. Albeit a secure time stamping service may provide a means of distinguishing between pre-and post-revocation signature, it hasn't been widely adopted due to its well-known prohibitive cost.
The basic idea of Server-Aided Signatures was introduced as a non-repudiation technique. Its goals are three-fold: Ÿ Assist small, limited-power devices in computing digital signatures Ÿ Provide fast revocation of signing capability Ÿ Limit damage from potential compromise The signature method (SAS) discussed here is based largely on a weak non-repudiation technique due to Asokan et al. (1999). The most notable feature of the SAS method is the introduction of an online partially trusted entity. Specifically, each SAS signature is generated with the aid of a partiallytrusted server called SEM (short for Security Mediator). Informally, the basic SAS signature protocol is as follows: Ÿ First, a prospective signer (Alice) contacts her SEM and provides the data to be signed as well as a one-time token. Ÿ SEM checks Alice's certificate validity and, if not revoked, computes a half-signature over the data as well as other parameters (including the one-time token). SEM then returns the results to Alice. Alice verifies SEM's halfsignature and produces her own halfsignature. Put together, the two respective half-signatures constitute a regular, full SAS signature. This signature is accompanied by SEM's and Alice's certificates.
The two half-signatures are inter-dependent and each is worthless in and of itself. This is despite the SEM's half-signature being a traditional public key signature: in the context of SAS, a traditional signature computed by a SEM is not, by itself, a SAS signature. The half-signature computed by a user (Alice, in our example) is actually a one-time signature (Shamir and Tauman, 2001) over the other half. Note that computing one-time signature requires little computation resource. Verifying a SAS signature is easy: after obtaining the signature, verifier (Bob) first verifies the correctness of SEM's public key signature, then checks the link between two halves i.e. verifies user's (Alice's) one-time signature.

Related works
A well-known technique which is online/offline signatures [1], in this scheme the signing of the message is broken into phases. The first phase is offline. Though it requires a moderate amount of computation; it presents an advantage in that it can be performed leisurely, before the message to be signed is even known. The second phase is online. It starts after the message becomes known, and utilizes the precomputation of the first phase and is much faster. A general construction which transforms any digital signature scheme to an online/offline signature scheme is presented entailing a small overhead. For each message to be signed, the time required for the offline phase is essentially the same as in the underlying signature scheme; the time required for the online phase is essentially negligible. The time required for the verification is essentially the same as in the underlying signature scheme (Shamir and Tauman, 2001).
In this paper, the signature is based on factoring and DES. In online, DES computation is used because it is ideally suited for electronic smart cards. All the costly computations are performed in the offline stage while the time for the online stage remains essentially unchanged. In some cases the transformed signature scheme is invulnerable to chosen message attack even if underlying digital signature scheme is not. It allows proving that the existence of signature schemes which are unforgeable by known message attack is a sufficient condition for the existence of signature schemes which are unforgeable by chosen message attack. It requires a lot of power for offline computation and this takes a longer time to compute (Asokan et al., 1997). This provides against denial by one of the entities involved in communication of having participated in all or part of the communication. Actually, nonrepudiation prevents either sender or receiver from denying a transmitted message. Thus, when a message is sent, the receiver can prove that the alleged sender in fact sent the message. Similarly, when a message is received, the sender can prove that the alleged receiver in fact received the message.
This is based on one-way hash functions and traditional digital signatures. It is efficient in terms of computation, communication and storage costs. The existing techniques for non-repudiation are based primarily on either symmetric or asymmetric cryptography. Secure symmetric techniques are computationally more efficient but require unconditional trust in third parties (Mundadugu et al 2001). Unconditional means that if such a third party cheats, the victim cannot prove this to the arbiter. Asymmetric techniques are computationally less efficient, but can be constructed in a way that allows one to prove cheating by the third parties involved. Server supported signature for non-repudiation of origin operates in one way hash function. This function operates on arbitrary length inputs to produce a fixed\ length value. A one-way hash function is said to be collision resistance if it is computationally infeasible to fine any two string. Full trusted usually implies poor scalability. Therefore the fully trusted server being a single point of failure in terms of security and availability becomes an attractive target for various attacks in many applications, it is impractical to establish a centralized fully trusted entity. A fully trusted server actually puts the users' security at risk as server compromise exposes all users' secret information.
There have been explosions in the number of applications for handheld devices. Many of these applications come with a remote device over an authenticated channel. Examples of applications include a wireless purchase using a cell phone, remote secure synchronization with a PDA, using a handheld device as an authentication token and handheld electronic wallets. According to authors, generating a 1024bit RSA key on handheld devices like palm-pilot can take as long as 15 minutes (Naor and Nissim, 1998). The device locks up while generating the key and is inaccessible to users. For wireless devices battery life time is a concern. The application may need to generate a key before it can function. Generating the key while the user is traveling will lock up the cell phone for some time and may completely drain the batteries. The obvious solution here is to allow the handheld to communicate with a desktop or server and have the server generate the key. The key can then be downloaded onto the handheld. The problem with this approach is that the server learns the user private key. Consequently, the server must be trusted by the user. Generating an unbalanced RSA key with the help of untrusted servers (Goodrich et al., 2001). At the end of the computation the servers should know nothing about the key they help generate. The assumption is that those two servers cannot exchange information with each other. This ensures that an attacker cannot eavesdrop on the network and obtain the information being sent to both servers. This approach limits mobility of the handheld application since users can only generate a key while communicating with their home domain. Server assisted one time signature scheme was recently presented as a non-repudiation service for mobile and constrained devices. However, the scheme suffered with high storage requirements for the virtual server and high memory requirements for the mobile client. This scheme significantly reduced virtual server storage requirements as well as mobile client memory requirements (Lamport , 1981). More precisely, the virtual server storage requirements in this scheme are reduced by a factor of more than 80 compared to the original scheme. Further, memory requirements for the mobile client are reduced by a factor of more than 130. This is done by generating various quantities pseudo randomly and storing just their cryptographic hash (instead of storing them fully) wherever possible, while still being able to perform dispute resolution. To have some legal significance, these transactions should have some form of non-repudiation (Goyal, 2004). This is usually provided through a digital signature. However, digital signature generation and even verification are known to be computationally intensive processes. It is not always practical to implement public key cryptography and hence digital signatures on a mobile device having limited computational resources and memory. The main problem here is high storage requirements for the verifiable server and memory requirement for the mobile clients. It is easy for the third party to cheat in this setting since it could sign any message on behalf of the user.

A. Model and notation
We distinguish among 3 types of entities: Ÿ Regular Users -entities who generate and verify SAS signatures. Ÿ Security Mediators (SEMs) -partially-trusted entities assisting regular users in generating SAS signatures. Ÿ Certification Authorities (CAs) -trusted offline entities that issue certificates and link the identities of regular users with SEMs. SEMs and CAs are verifiable third parties from the users' point of view.
All participants agree on a collision-resistant oneway hash function family H and a digital signature scheme. In SAS, the latter is fixed to be the RSA scheme Yung, 1989, Boneh et al., 2001)

SAS description
The SAS system consists of four component algorithms: Setup, Sign, Verify, and Renew. Setup initializes the settings for SEMs and regular users; Sign computes SAS signatures on given messages, which can later be validated by running Verify. Handoff algorithm allows a regular user to switch from one SEM to another (Ding et al., 2001). Renew algorithm allows a user to use new one time private keys (a hash chain as shown below) without applying for a new certificate.

A. Setup
The system administrator sets up a CA and initializes a system-wide cryptographic setting. Specifically, the administrator selects a collisionresistant oneway hash function H( ) for the users. The choices of H( ) include SHA-224 and SHA-256, which are massumed to be secure. A public key signature scheme, which is secure against adaptive chosen message attacks, is selected for SEMs. In order to minimize computation overhead for regular users, the chosen public key signature scheme should be efficient for verifiers. (This is because, as will be seen later, verification is done by regular users, whereas, signing is done by much more powerful SEMs.) Therefore, choose RSA signature scheme (Askan et al 1997, Shamir and Tauman, 2001) with a small public exponent, such as 3 and 65,537 for SEMs.
To become a SAS signer, Ui customizes H( ) into Hui ( ). In essence, Hui ( ) is a keyed hash (e.g., Mackenzie and Reiter, 2001) with a known key set to the identity of the signer. Then, Ui generates a secret random element SK0 i and chooses n as the number of messages to sign. Starting with this value, Ui computation is as follow: Ui's key chain. Each SKj i , for 0 < j < n is Ui's j-th (one-time) private key. It subsequently enables Ui to produce (n-1) SAS signatures, since as shown below, each of them will be used only once. publicly available via a directory service such as LDAP.

B. SAS signature protocol
To get the first signature from SEM, U needs to i register herself to her assigned SEM either off-or online. In the off-line case, SEM obtains U s SAS i' certificate via manual (local or remote) installation by an administrator or by fetching it from the directory service. To register on-line, U simply includes her i SAS certificate as an optional field in the initial SAS signature request to the SEM. Before processing the request as described above, the SEM checks if the same certificate is already stored. If not, it installs in the certificate database and creates a new user entry. To run the same protocol with an alternative SEM, U i must run. In the initial run of the protocol, the signature counter k is set to n- Step 2. On receiving U 's request, SEM obtains Certi i (either from the request or from local storage) and checks its status. If revoked, SEM replies with an error message and halts the protocol. Otherwise, SEM compares the signature counter in the request to its own signature counter. In case of a mismatch, SEM replies to U with the half-signature produced in the i last protocol run and aborts. (Note that SEM keeps a record of all previously generated half-signatures) Then, SEM proceeds to verify the received k-th k "private" key (SK ) with U 's root public key in Certi. attributes may also be included in SEM's halfsignature, e.g., a timestamp. SEM decrements U 's i signature counter, records the half-signature and returns the latter to U . i In the above, SEM assures that for a given SAS certificate exactly one signature is created for each k SK . This property is referred to to as the SAS i Invariant. This concept enables non-repudiation for SAS signatures and protects users from being framed by SEMs.
Step 3. U (who is assumed to be in possession of SEM's certificate) verifies SEM's half-signature, records it and decrements her signature counter. If SEM's half-signature fails verification or its attributes are wrong (e.g., it signs a different message than m or includes an incorrect signature counter j ≠ k), U aborts the protocol and concludes that a hostile attack has occurred. In the end, U 's SAS signature on i message m has the following format: The second part, namely SK is U 's half- consistently maintain the counter by decrementing it after each run. The protocol is illustrated in Figure 1.
Step 1. U starts by sending a request containing: easy to see that, owing to the trusted nature of a SEM and the SAS Invariant, light verification is usually sufficient. However, if a stronger property (such as non-repudiation) is desired, full verification may be used.

D. SAS renewal
A renewal is needed when the messages to sign outnumber the length of the key chain, or the states between SEM and the user is inconsistent due to attacks or system failures. The renewal protocol allows a user to use a new chain of private keys without applying for a new certificate, on the condition that her seed private key is not compromised. Suppose user U is currently using the i 0 hash chain seeded with SK and the SEM is expecting i k 0 SK . To shift to a new chain seeded with SK , U and i i i SEM run the following protocol: Step 1: In order to sign w messages in the future, U i 0 generates a new hash chain of length w + 1: SK ……. In this scheme is design to help solve majority of the problem which is faced by smart devices. This scheme provides a solution to the source authentication problem under the assumption that the sender and the receiver are loosely time synchronized. SAS protocol has the following properties; low computation overheads, low communication overheads, if a packet arrives in time the receiver can verify its authenticity. The two half signatures are interdependent, so each is worthless and of itself. Step 2: SEM checks the authenticity of SK ) and U 's i i certificate status as in SAS signature protocol. If the renewal is approved, SEM returns a signature on the request as a normal SAS signature. Meanwhile, the state is updated so that any future SAS signature requests using this chain will be rejected and an attack alarm should be signaled.
Step 3: If SEM's signature in the second round is w 0 verified valid, U reveals to SEM the SK and Sk i i i

Conclusion
The above protocol is implemented in java and it is run on various Speed of Pentium processors. All the experiment was conducted over 100Mbps Ethernet LAN in a Lab, run a number of tests with various hardware platforms and different RSA key sizes and also implement this protocol in Email system, where mail will be encrypted and sent. When ready to send, the user's SAS certificate and extracts the SEM address. SAS-signed emails can be verified by any S/MIME capable email client such as Netscape or Microsoft. The result obtained after running the SAS protocol and RSA on different Systems have been presented.