DESC:The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-

TECHNICAL FIELD
The embodiments herein generally relate to the field of authentication and more particularly to authentication in a Proxy Re-Signature (PRS) based system.

BACKGROUND
Technological development in field of machine-to-machine communication or human to machine communication has considerably introduced automation in systems such as Internet of Things (IoT). Multitude of applications such as Vehicular Ad Hoc Networks (VANETs) epassport system, digital certificate issuing systems, and the like come under the broad umbrella of IoT. Authentication of entities involved, such as electronic devices and end users, in the system is utmost important for applications of IoT. To address this enormity, delegation of authentication becomes a critical tool for authentication management of a system. The traditional concepts of Proxy Re-Signature (PRS) and Proxy Re-Encryption (PRE) are the essential primitives for secure delegation. The PRE is used in applications where it is required to securely enable a re-encryption of ciphertexts from one key to another, without relying on trusted parties, also referred as semi-trusted proxy devices. The PRS is used in application where a semi-trusted proxy device (proxy) between two parties (users) A and B converts a signature on a message, say m, signed by the user A to the signature of the other user B on the same message m. The user A is referred as a delegatee A and user B is referred as a delegator B. The proxy device is provided with the capability and information (Re-Signature Key) to perform the task of re-signing. This kind of signature comes handy in situations or applications where delegator B is unavailable to sign on the given message (m). Then, using a signature of the delegatee A on the message (m), the semi-trusted proxy device can generate a signature on behalf of delegator B on the same message (m) with the help of a rekey (Re-Signature Key), without involving delegator B in the signing process.
Conventionally the delegator B must have a strong control over the delegation and signing process since the signature is going to be verified with his/her public key. However, in existing proxy re-signature implementations, the semi-trusted proxy has unconditional power to translate any signature of the delegatee A to that of the delegator B. This can introduce a critical issue in PRS implementations, since there is no control over the kind of messages the proxy can translate. A major loophole while delegating authentication is when the delegator B loses control over what messages are authenticated by the delegatee A. In this case the delegator B will not have any means to deny signatures, which were not signed by him since the translated signatures by the proxy device will verify with the delegator B’s public key. Further, there are no means available to prove the fact that the signature was translated with the consent of the delegatee A. This issue can pose a real threat in applications like temporary certificate generation for Public Key Infrastructure (PKI) and signature delegations in organizations.

OBJECT OF INVENTION
The principal object of the embodiments herein is to provide a method and a conditional Proxy Re-Signature (PRS) based system (system) for delegation of authentication using a conditional PRS scheme, wherein the conditional PRS based scheme allows the proxy device to translate a delegatee signature for a message to a re-signature using a conditional Re-Signature Key (RSK) received from a delegator.
Another object of the embodiments herein is to provide a method that provides a security threat model for the conditional PRS system that implements the conditional PRS based scheme, wherein the security threat model allows verifying robustness of the conditional PRS system against adversaries.

SUMMARY
In view of the foregoing, an embodiment herein provides a method for delegation of authentication in the Proxy Re-Signature (PRS) based system. The method includes receiving a message from a delegatee, wherein the message is signed with a delegatee secret key and appended with a condition. Further, the method includes verifying the condition received with the message to a Signature Translation (ST) condition defined by a delegator for translating a delegatee signature for the message to a re-signature for the message. Further, the method includes translating the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) generated for the ST condition when the condition received in the message verifies with the ST condition.
Embodiments further disclose a conditional Proxy Re-Signature (PRS) system for delegation of authentication, wherein the system comprises a proxy device, a delegator, a delegatee and at least one entity, wherein the proxy device is configured toreceive a message from a delegatee, wherein the message is signed with a delegatee secret key and appended with a condition. Further, the proxy device is configured to verify the condition received with the message to a Signature Translation (ST) condition defined by a delegator for translating a delegatee signature for the message to a re-signature for the message. Further, the proxy device is configured to translate the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) generated for the ST condition when the condition received in the message verifies with the ST condition.
Embodiments further disclose a proxy device for delegation of authentication in a conditional Proxy Re-Signature (PRS) system, wherein the proxy device comprises a re-signature module. The re-signature module is configured to receive a message from a delegatee, wherein the message is signed with a delegatee secret key and appended with a condition. Further, the re-signature module is configured to verify the condition received with the message to a Signature Translation (ST) condition defined by a delegator for translating a delegatee signature for the message to a re-signature for the message. Further, re-signature module is configured to translate the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) generated for the ST condition when the condition received in the message verifies with the ST condition.
These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES
The embodiments of this invention are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:
FIG. 1 illustrates an example conditional Proxy Re-Signature (PRS) system for delegation of authentication using a conditional PRS scheme, according to embodiments as disclosed herein;
FIG. 2 illustrates a plurality of components of a proxy device of the conditional PRS system utilizing the conditional PRS scheme, according to embodiments as disclosed herein;
FIG. 3 illustrates a plurality of components of a delegator of the conditional PRS system utilizing the conditional PRS scheme, according to embodiments as disclosed herein;
FIG. 4 illustrates a plurality of components of a delegatee of the conditional PRS system utilizing the conditional PRS scheme, according to embodiments as disclosed herein;
FIG. 5 is a flow diagram illustrating a method 500 for delegation of authentication using the conditional PRS scheme for in the conditional PRS system, according to embodiments as disclosed herein; and
FIGs. 6a and 6b is an example conditional PRS system implemented in Vehicle Ad-hoc Networks (VANETs) that utilizes the conditional PRS scheme, according to embodiments as disclosed herein.

DETAILED DESCRIPTION
The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
The embodiments herein achieve a method and a conditional Proxy Re-Signature (PRS) system (system) for delegation of authentication using a conditional PRS scheme. The conditional PRS based scheme allows the proxy device to translate a signature of a delegatee (delegatee signature) for a message to a re-signature using a conditional Re-Signature Key (RSK) available to the proxy device. The conditional RSK is generated using a delegator secret key from the delegator, a delegatee public key from the delegatee and the ST condition, in accordance to a protocol among the delegator, the delegatee and the proxy device. The re-signature is a signature of the delegator (delegator signature). The proxy device can translate the signature only when a signature translation (ST) condition defined by the delegator for translating the delegatee signature for the message to the re-signature for the message is verified at the proxy device. Further, the method includes sending the message with the re-signature to one or more entities of the conditional PRS system destined to receive the message. The re-signature is identical to a delegator signature and can be easily verified by one or more entities using the delegator public key.
Thus, the method proposed provides a control of the delegator over the proxy device by introducing the ST condition verification criteria before translating the delegatee signature to the re-signature. The method also provides control of the delegator over the delegatee, whose request to translate the signature to the re-signature is not serviced if the ST condition criteria fail.
Further, the method includes providing a security threat model for the conditional PRS system. The security threat model allows verifying robustness of the conditional PRS system against adversaries.
In an embodiment, the proxy device is a server or a mobile phone or a desktop, a laptop, a personal digital assistant, a wearable device or any other electronic device.
In an embodiment, the delegator is a server or a mobile phone or a desktop, a laptop, a personal digital assistant, a wearable device or any other electronic device.
In an embodiment, the delegator is a server or a mobile phone or a desktop, a laptop, a personal digital assistant, a wearable device or any other electronic device.
Referring now to the drawings, and more particularly to FIGS. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
FIG. 1 illustrates an example conditional Proxy Re-Signature (PRS) system 100 for delegation of authentication using the conditional PRS scheme, according to embodiments as disclosed herein. In an embodiment, the conditional PRS system 100 includes a proxy device 102 configured to function as a proxy for a delegator 104 for translating the delegatee signature on the message (m) received from a delegatee 106 (delegatee A) to that of the delegator 102 (delegator B).
The delegator 104 can be configured to delegate authentication to the delegatee 106 to act on delegator’s 104 behalf. However the authentication rights can be restricted with a condition, which is the ST condition in the conditional PRS based scheme proposed. The delegatee 106 may intend to transmit the message (m) to one or more entities 1081 to 108n of the conditional PRS system 100 on behalf of the delegator 104 with assistance from the proxy device 102. The proxy device 102 can be configured to translate the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) received by the proxy device. The delegator 104 can be configured to generate and send the conditional RSK to the proxy device 102 along with the ST condition. The delegator 104 shares the ST condition with the delegatee 106 and delegates the authentication rights to the delegatee 106 limited with the ST condition. Thus, a message signed with delegatee signature (S) is translated to a message signed with delegator signature or the re-signature (S’). Thus, the delegatee signs the message using a delegatee secret key and appends the ST condition with the message. In an embodiment, the conditional RSK is a unidirectional key (RSKA-B) for translating the delegatee signature to the re-signature, wherein the re-signature is the delegator signature. The conditional RSK is generated using the delegator secret key from the delegator 104, the delegatee public key from the delegatee 106 and the ST condition set by the delegator 104, in accordance to the protocol. In an embodiment the protocol can be an interactive protocol or a non-interactive protocol. The proxy device 102 can be configured to translate the signature using the conditional RSK only when the ST condition defined by the delegator 104 is verified for the message received from the delegatee 106. Upon translating the signature, the proxy device 102 can be configured to send the message signed with the re-signature to one or more entities 1081 to 108n destined to receive the message. The re-signature is identical to the delegator’s 104 signature (delegator signature) and can be easily verified by one or more entities 1081 to 108n using the delegator public key.
An example of Vehicle Ad-hoc Networks (VANETs) which is a use case scenario where the proposed conditional PRS system 100 implementing the conditional PRS scheme is utilized is explained in conjunction with FIG. 6. Some use case scenarios in technical applications of the conditional PRS system 100 are mentioned below.
The proposed conditional PRS system 100 with conditional PRS scheme can be used in a controlled broadcasting for any reputed organization. For example, organizations broadcast messages using outsourced Public Relation Officers (PROs). To maintain authenticity, all messages broadcast can be verified by the organization’s public key. The person in charge of sending out the messages on behalf of the organization (delegator B) is a PRO (delegatee A). So when the PRO (delegatee A) generates a broadcast message, it is authenticated using his secret key to verify whether it had come from the PRO (delegatee A). A semi-trusted proxy server (proxy device 102) in turn converts the PRO’s (delegatee A) signature to that of the organization’s (delegator B) signature and releases the message (m). In case the organization intends to impose some policies on the kind of messages signed by the PROs (delegatee A), a condition (ST condition) can be embedded in the re-signature keys (conditional RSKs) provided to the proxy device 102. Thus, if the PRO generates a broadcast of irrelevant information then the proxy device 102 is not able to convert the signature if the authenticity of the information is not verified as defined by the conditional RSK.
The proposed conditional PRS system 100 with conditional PRS scheme can be used in an e-passport system. In the e-passport system, a passenger goes through a number of check points like immigration, baggage check, security scan and so on. The signature of each checkpoint is verified sequentially as the passenger goes through the system. In order to store less amount of information, PRSs are used. Signatures of each checkpoint are translated and verified on the fly. The proxy device 102 translates the signature of a previous checkpoint to that of the next checkpoint as the passenger progresses. This application can be more stringent, with a set of predefined conditions (ST condition) introduced. For example, consider physically challenged and senior citizens who might not have to go through the entire checking process. There can be certain new check points which can leverage the amount of checking based on the above mentioned conditions. The proxy device 102 can have the re-signature key information (conditional RSK), which can convert only signatures for people with these special conditions, hence making the system more realistic. In this system the adjacent checkpoints are the delegatee and the delegator.
The proposed conditional PRS system 100 with conditional PRS scheme can be used in a certificate issuing system for issuing certificate in a public key setting. Since, issuing certificate is a very expensive process, the proxy re-signatures have introduced the concept of delegation for temporary users to participate in the certificate issuing system. The signatures of the temporary users (delegator B) who are not certified by the PKI (Public Key Infrastructure) can be converted to that of another valid certified user (delegatee A) depending on the application with the help of the proxy device. This can also be extended to delegating signing rights between users (delegators) who were certified by different Certification Authorities (CA). In the conditional PRS scheme implementation in the certificate issuing system, the proxy device 102 is provided the information to only translate signatures from certain CAs’ (ST condition) rather than that of an arbitrary CA.
Further, the proposed conditional PRS system 100 can be used in a conventional approach in a hierarchical organization where the proxy device 102 can translate signatures of a temporary official (delegatee A) to that of a higher authority (delegator B). The proxy device 102 can be granted freedom to convert signatures on only those messages from the temporary official that obeys a certain condition (ST condition) rather than translating signature on any random message that the temporary official generates.
The proposed conditional PRS system 100 can be used in a cloud infrastructure, where data is constantly pumped in and out of a cloud server through various client systems such as mobile phones, desktops, storage devices and the like. The clients (delegators) must ensure that the cloud server (delegatee) does not misuse the data once it enters the cloud server. Further, the cloud server must also ensure that harmful client data must not enter the cloud infrastructure. The conditional PRS scheme can be helpful in this scenario, when signatures on data are translated between the client and the cloud server. Here, a middle-ware proxy (proxy device 102) is constrained to ensure the interests of the user and the cloud (ST condition) without any misuse of data through unconditional translation.
The proposed conditional PRS system 100 can be used in an organization, where during an internal audit; identity of employees can be concealed by translating their signatures to that of the organization’s corporate identity (organization’s signature) in order to preserve employee profile and organization structure. Here, the proxy device 102 can be constrained by a conditionality feature to translate signatures only during the time of audits (ST condition) and not during normal operation.
The ST condition can also be used as an approach to constrain all users of a system to a global clock. The signatures and the re-signatures can comprise of time-units instead of the conditions. Hence every signature is inherently logged by itself. This property can be useful in applications, which are time sensitive like two level transactions and many others. The property of forward security can also be realized with the use of ST condition.
The conditional PRS scheme is defined by the following set of six functions: (Setup, KeyGen, ReKey, Sign, ReSign, Verify) which are defined as follows.
Setup (k) - This function takes a security parameter (k) such as 2048 for a Risk-Based Authentication (RSA) system and 1024 for a Diffie Hellman based system of the conditional PRS system parameter (params) to construct a common string. The common string is required for the delegator, the delegatee and other entities in the conditional PRS system to generate their own keys.
KeyGen() - This function uses the common string generated from the Setup function to generate a public-secret key pair for any entity of the conditional PRS system that invokes the function KeyGen(). The generated public keys are certified by at least one Certification Authority (CA) for the conditional PRS system. Thus, the KeyGen() generates the delegatee public key (pkDelegatee) and the delegatee secret key (skDelegatee) pair for the delegatee, and the delegator public key (pkDelegator) and the delegator secret key (skDelegator) for the delegator.
ReKey(skDelegator,pkDelegatee,C) - This function is a protocol to generate the condition RSK, wherein the protocol may be interactive or non-interactive The function takes the delegatee secret key (skDelegatee) and the delegator secret key (skDelegator) between whom the conditional RSK must be generated, and the ST condition (C). The RSK is kept secret with the proxy device. The RSK is structured in such a way that the proxy device cannot gain any advantage regarding the secret keys of the delegator and the delegatee.
Sign (m,C,sk) - This function enables the delegatee, the delegator or any other entity of the conditional PRS system to sign a message (m) for the ST condition (C). The function generates sign on the message (m) based on message (m), condition(C) provided by a corresponding entity invoking this function and the secret key (sk) of the corresponding entity who is signing the message (m).
ReSign (m,C,s,pkDelegator,pkDelegatee) – The function applies the conditional RSK on the message (m), the ST condition (C), the delegatee signature (s), the public key of the delegator and the delegatee (pkDelegator and pkDelegatee) and translates the delegatee signature (s) into a re-signature (s ^ ) after verifying that the ST condition (C) in the message (m) matches with the ST condition (C) set by the delegator. The message signed with the re-signature can be verified (ST condition true) by the one or more entities in the conditional PRS system using the public key of the delegator (pkDelegator). If the ST condition is not verified (STcondition false) then the function returns NULL indicating an invalid signature.
Verify(m,C,s,pk) - This function is used by one or more entities in the conditional PRS system, for which the message (m) signed with the re-signature is destined, to verify that the message (m) is an authentic message from the delegator. The function takes parameters such as the message (m), the condition (C) (where, C is part of the delegator’s public signature), the signature/re-signature (s) on the message (m) and the public key pk of the sender of the message (for example, the delegator). The function returns true if the signature is successfully verified with respect to the message, condition and public key and returns false otherwise.
Further, the security threat model for verifying robustness of the conditional PRS system against adversaries is provided. In security model for conditional PRS, the security of the signatures is established using the notion of existential unforgeability against adaptive chosen message attack, where the adversary is able to come up with forgeries on messages for which he had not queried for the signatures. Embodiments herein use the same security notion (but with a stronger unforgeability notion where existing message signature pairs cannot be forged) and disclose the security threat model to incorporate conditions (chosen condition attack). There are two existing standard security models of proxy re-signatures - static corruption and dynamic corruption based on which embodiments herein define the security models for conditional proxy re-signatures.
Embodiments herein utilize a more applicable model, a static corruption model, for proving the security of the conditional PRS scheme proposed for the conditional PRS system. In this security threat model, a challenger who is proving the security of the conditional PRS scheme, initially trains the adversary who queries a set of oracles which define the behavior of the conditional PRS system (oracles for conditional PRS schemes defined below). On the RSK generation being queried, a delegation chain is constructed. For example, if the rekey for an entity A to an entity B and an entity B to an entity C is generated, then all the signatures’ of A can be indirectly converted to that C by the proxy device. The use of conditions, such as the ST condition, may restrict this type of insecurities in the delegation chain. In the static corruption model, since the challenger can differentiate between the corrupted and uncorrupted users beforehand, it simulates the appropriate oracles for the discussed in detail below.
Corrupted Key Generation Oracle: For a corrupted user (entity), the challenger generates and outputs the private key and the corresponding public key.
Uncorrupted Key Generation Oracle: For an uncorrupted user (entity), the challenger generates the private key and outputs only the public key.
ReKey Oracle: For the input of the secret keys and the condition, the challenger outputs the corresponding conditional RSK between the users for the corresponding condition.
Uncorrupted Signature Oracle: Given the input of the uncorrupted user’s public key, the message and the corresponding condition to sign on, the challenger outputs the corresponding signature.
Re-Signature Oracle: Given input, the signature on the message and condition of the corresponding user and the public key of the user to whom the signature is to be translated to, the challenger outputs the corresponding conditional RSK on the same message and condition for the given user.
The adversary controls the actions of the corrupted users. At the end of the training phase, the adversary does not have any advantage with respect to the information of the uncorrupted users. The adversary can query the above mentioned oracles considering its limited computation power. Undesirable delegation chains between corrupted and uncorrupted parties can be avoided by the use of conditions, such as the ST condition.
In the forgery phase, it can be concluded that the conditional PRS scheme of the conditional PRS system is secure if the adversary with the access to all these oracles, is able to come up with a valid forgery on the signature or the re-signature with respect to a condition and a message for an uncorrupted user with respect to some conditions as discussed below:
Let ((m,) ¯C ¯) represent the message, condition that were already queried to the sign/re-sign oracle with respect to an uncorrupted user(¬¬¬¬¬¬¬¬¬¬(pk) ¯). Let (m*,C*) represent the message, condition pair for which the forgery is generated for an uncorrupted user pk*. Forgery s* is valid if satisfies the following constraints as provided by an equation 1 below :
Verify (pk*,m*,C*) = True` (1)
If s* ? s where s is an output of Osign(m*,C*) or Oresign(m*,C*,¬¬¬¬¬¬¬¬¬¬(pk) ¯, pk*). Or there is a delegation chain with C* from ¬¬¬¬¬¬¬¬¬¬(pk) ¯ to pk*.
If ((m*,C*) ? ((m,) ¯C ¯)) or (m* ? (m,) ¯) or (C* ?(C,) ¯).
The adversary has not made a rekey query chain to delegate the signing rights from a corrupted pk* on the condition C*.
Embodiments herein define the advantage of the forger as the probability that he/she wins in the above game. The resulting conditional PRS scheme is strongly unforgeable against the chosen message and condition attack if the above mentioned forgery can be performed only with a negligible probability. Thus, with the security threat model proposed, the forger is not able to derive any undue advantage as a consequence of the introduction of the condition such as the ST condition. The introduction of condition reduces the number of constraints on the forgery as when compared to a traditional proxy re-signature scheme.
Since the security threat model is an enhancement of an existing method, the above described security threat model can be extended to the chosen key model. The unidirectional PRS schemes that use the unidirectional RSK, and having the private proxy device are secure in this security threat model and any other model.
Below is provided the mathematical description that explains the conditional PRS scheme implemented by the condition PRS system 100. Let G be an additive cyclic group generated by P, with prime order p, and G_1 be a multiplicative cyclic group of the same order p. A bilinear pairing is a map e ^ : G x G ? G_1 with the following properties as provided by equations 2-4 below.
Bilinearity: For all P, Q, R ? G,
- e ^(P+Q,R) = e ^(P,R) e ^(Q,R) (2)
- e ^ (P,Q+R) = e ^(P,Q) e ^ (P,R) (3)
- e ^ (aP,bQ) = e ^(P,Q)ab (4)
Non-Degeneracy: There exists P,Q ? G such that e ^ (P, Q) ? I_(G_1 ) , where I_(G_1 ) is the identity in G_1.
Computability: There exists an efficient function to compute e ^ (P, Q) for all P, Q ? G.
In Computational Diffie-Hellman Problem, let G be a group of prime order p and g be the generator of G. The CDH problem can be defined as follows: An function A is said to have an advantage ? in solving the CDH problem if it satisfies condition as provided by an equation 5 below:
Pr?[A(P,aP,bP)=abP]= e (5)
Where, the probability is calculated over the random choices of a,b ? Z_p^*,g? G^* and the random bits used by function A.
Embodiments herein define a Public Key Infrastructure (PKI) based conditional PRS scheme for the PRS system 100, which is based on pairing. The security is asymptotically based on a security parameter k. The mathematical analysis of the conditional PRS scheme implemented for conditional PRS system 100 is provided below:
Setup(k) and KeyGen()- Let G and G_1 be cyclic groups of prime order p defined to satisfy the billinear map e ^ : G x G ? G_1. P is chosen as the generator of G. The set of hash functions are defined as truly random oracles as provided by equations 6-9 below:
H1: {0,1}* ? G (6)
H2: {0,1}* x G x G ? G (7)
H3: {0,1}* x {0,1}* x G ? G (8)
H5: {0,1}* x {0,1}* x G x G ? G (9)
Each user, such as the delegator, the delegatee and the like, using the public parameters defined above generates their own private and public key pair after which each user certifies the public key with the certification authority. Consider x ? ? Z?_p as the user’s private key. The public key is computed as xp ? G. For the mathematical analysis of the conditional PRS scheme the delegatee here, for example, is a delegatee (X) with respect to x and the delegator, for example, is a delegator (Y) with respect to y.
In certain cases, embodiments herein may assume a heuristic black box (K(m)=C) that when given the input message ’m’, it returns the condition(s) ’C’, that corresponds to the message. This may not be applicable for some applications where the condition depends on the situation (example: urgency) and not the type of message.
ReKey(x,y,C): The conditional RSK is generated for the condition C(rk_(x?y) (C)) using the interactive protocol which indirectly accepts the secret keys of the X and Y without revealing it to the proxy device. The proxy device selects elements R ?G and r_2 ? ? Z?_q and sends R and r_2 P to the delegator(Y). The Y then computes data as provided by an expression 10 below
yH_1 (C)+yH_2 (C,r_2 P) ?G (10)
Where, y is the secret key and C is the condition, such as the ST condition, for which the delegator (Y) chooses to delegate its signing rights. Y sends data as provided by an expression 11 below:
yH_1 (C)+yH_2 (C,r_2 P)+R ?G (11)
and the ST condition (C) to the delegatee(X). X computes xH_1 (C) and sends data as provided by an expression 12 below:
yH_1 (C)+yH_2 (C,r_2 P)+R-xH_1 (C)?G (12)
to the proxy device. The proxy device removes R and assigns the RSK from X to Y for the condition C as provided by equations 13 and 14 below:
r_k1=(y-x) H_1 (C)+yH_2 (C,r_2 P)?G (13)
r_k2=r_2 P?G (14)
The role of R is to prevent X and Y from misusing the intermediate information and r_2 is known by the proxy device and is used in the resign function. Embodiments herein use the interactive rekey function while constructing the conditional PRS scheme so that the proxy device can re-use the randomness in the resign function, thereby reducing the space required and computation time of the re-signature.
Sign (m,C,x): Given the input as message(m), condition(C) and the secret key(x) of the signer, the function performs the steps including choosing a random r_1 ? ? Z?_p and compute r_1 P?G, assign s_1=xH_1 (C)+ r_1 H_3 (m,C,r_1 P) and assign s_2=r_1 P. Hence, the output signature for message m and condition C for the user X is ?(s?_1,s_2).
ReSign ( ): Given the input as message(m), condition(C), public key (xP) for the corresponding signature( ) and the re-signature key rk_(x?y) (C), the re-signature function performs the following steps
Step 1: Verify (s,xP,m,C) is invoked in order to check the validity of the signature to be translated with respect to the delegatee’s public key (xP). If this test does not hold, the translation is meaningless. Hence, the resign function can continue only if it satisfies this test. Step2: Compute and store re-randomization component as r_2 H_5 (m,C,r_2 P,r_1 P)?G, where r_2 is from the rekey function. The hash function includes the randomness introduced during the sign and rekey function to maintain the integrity of the resultant re-signature. Step3: The translated signature is computed as provided by equations 15 and 16 below
(s_1 ) ^= ?{s?_1}+{?rk?_1} + {Re-Randomization component} (15)
(16)
Step 4: assign (s_2 ) ^= s_2= r_1 P. Step 5: assign (s_3 ) ^= ?rk?_2= r_2 P. Hence, the output re-signature s ^ for message m and condition C for the user Y is ((s_1 ) ^(?,s?_2 ) ^(,s_3 ) ^).
Verify(s,xP,m,C): The verify function takes as input the signature( )/re- signature(s ^) of the user X on the message (m) for the condition (C) and returns true if the signature is a valid one. The function performs the following to check if it is a valid signature using equation 17 provided below: (17)
Where, the signature is of the form as provided by equation 18 below:
(18)
The function performs the following to check if it is a valid re-signature as provided in equation 19 below: (19)

Where, the re-signature is of the form as provided in equation 20 below: (20)
If the above test fails, the signature is invalid. Further, correctness of signature verification is performed as provided in equation 21 below: (21)
Further, correctness of the re-signature verification is performed as provided in equation 22 below: (22)
Efficiency Analysis: It can be observed that, the signature includes two group elements and the re-signature only increases the size by an extra group element, due to the extra randomness component introduced by the ReSign function. On the computation complexity, the Sign function requires three scalar multiplications and one group addition in G. The ReSign function requires one scalar multiplication and three group additions in G. The verify function for a signature requires three pairing operations and one group multiplication in G_1 while the verify function for a re-signature requires five pairing operations and three group multiplications in G_1.
FIG. 2 illustrates a plurality of components of the proxy device 102 of the conditional PRS system 100 utilizing the conditional PRS scheme, according to embodiments as disclosed herein. Referring to figure 2, the proxy device 102 is illustrated in accordance with an embodiment of the present subject matter. In an embodiment, the proxy device 102 may include at least one processor 202, an input/output (I/O) interface 204 (herein a configurable user interface), a memory 206. The at least one processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 206.
The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, and the like. The I/O interface 204 may allow the proxy device 102 to communicate with other devices such as the delegator 104, the delegatee 106 and one or more entities1081 to 108n. The I/O interface 204 may facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, Local Area network (LAN), cable, and wireless networks, such as Wireless LAN, cellular, Device to Device (D2D) communication network, Wi-Fi networks and so on. The modules 208 include routines, programs, objects, components, data structures, and so on, which perform particular tasks, functions or implement particular abstract data types. In one implementation, the modules 208 may include a re-signature module 210. The re-signature module 110 can be configured to generate the conditional RSK using the ReKey function for the ST condition. The ST condition is defined by the delegator 104 who delegates authentication to the delegatee 106 for the ST condition. This ST condition is to be verified by the proxy device 102 for translating the delegatee signature for the message to the re-signature for the message. The proxy device can be configured to receive the conditional RSK from the delegator along with the ST condition. The RSK is generated by the delegator using the delegator secret key from the delegator 104, the delegatee public key from the delegatee 102 and the ST condition defined by the delegator 104 in accordance with the protocol associated with the ReKey(skDelegator,pkDelegatee,C) function among the delegator 104, the delegatee 106 and the proxy device 102. The conditional RSK is the unidirectional key for translating the delegatee signature to the re-signature held secret only with the proxy device 102 and mathematically represented as conditional RSKA-B or RSKDelegatee-Delegator.
Once the proxy device has the conditional RSK, then the re-signature module 110 can be configured to receive the message from the delegatee 106. The message from the delegatee 106 is signed with the delegatee secret key (skDelegatee) and is appended with a condition, wherein the condition is to be verified with the ST condition. Thus the signed message (m) from the delegatee 106 is mathematically represented as, S= sign (skDelegatee,condition,message). Further, the re-signature module 110 can be configured to verify the condition received with the message to the ST condition defined by the delegator 104. Further, the re-signature module 110 can be configured to translate the delegatee signature for the message to the re-signature using the conditional RSK when the condition received in the message verifies with the ST condition such that condition= STcondition (C). Thus mathematically represented as, S= sign (skDelegatee,condition,message) converted to S’= re-sign (S, RSKdelegatee-delegator, ST condition (C)).
Further, the re-signature module 110 can be configured to send the message signed with the re-signature, S’= re-sign(S, RSKDelegatee-Delegator, ST condition (C)), to one or more entities 1081-108n of the conditional PRS system 100 destined to receive the message. The re-signature is identical to delegator’s 104 signature and can be easily verified by one or more entities 1081 to 108n using the delegator signature. The modules 208 may include programs or coded instructions that supplement applications and functions of the proxy device 102. The data 212, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules 208. Further, the names of the other components and modules of the proxy device 102 are illustrative and need not be construed as a limitation.
FIG. 3 illustrates a plurality of components of the delegator 104 of the conditional PRS system 100 utilizing the conditional PRS scheme, according to embodiments as disclosed herein. Referring to figure 3, the delegator 104 is illustrated in accordance with an embodiment of the present subject matter. In an embodiment, the delegator may include at least one processor 302, an input/output (I/O) interface 304 (herein a configurable user interface), a memory 306. The at least one processor 302 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 302 is configured to fetch and execute computer-readable instructions stored in the memory 306.
The I/O interface304 may include a variety of software and hardware interfaces, for example, a web interface, and the like. The I/O interface 304 may allow the delegator device 104 to communicate with other devices such as the proxy device 102 and the delegatee 106. The I/O interface 104 may facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, Local Area network (LAN), cable, etc., and wireless networks, such as Wireless LAN, cellular, Device to Device (D2D) communication network, Wi-Fi networks and so on. The modules 308 include routines, programs, objects, components, data structures, and so on, which perform particular tasks, functions or implement particular abstract data types. In one implementation, the modules 308 may include a conditional PRS module 310. The conditional PRS module 310 can be configured to generate the common string using the Setup (k) function for the parameter k of the conditional PRS system 100. Further, the conditional PRS module 310 can be configured to generate delegator public key (pkDelegator) and the delegator secret key (skDelegator) using the KeyGen() function. Further, the conditional PRS module 310 can be configured to communicate with the proxy device 102 and the delegatee 106 through the protocol associated with the ReKey(skDelegator,pkDelegatee,C) function to generate the conditional RSK and send it to the proxy device 102. The conditional RSK is unidirectional and allows the signature translation only of the delegatee 106 (delegatee A) to the delegator 104 (delegator B) as can be mentioned as conditional RSKA-B or RSKdelegatee-delegator. Once the conditional RSK is generated and shared, and the ST condition is shared with the delegatee 106 the delegator 104 is not required to communicate with the proxy device 102 or the delegatee 106 for transmitting the messages. The modules 308 may include programs or coded instructions that supplement applications and functions of the delegator 104. The data 312, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules 308. Further, the names of the other components and modules of the delegator device 104 are illustrative and need not be construed as a limitation.
FIG. 4 illustrates a plurality of components of a delegatee106 of the conditional PRS system 100 utilizing the conditional PRS scheme, according to embodiments as disclosed herein. Referring to figure 4, the delegatee106 is illustrated in accordance with an embodiment of the present subject matter. In an embodiment, the delegatee 106 may include at least one processor 402, an input/output (I/O) interface 404 (herein a configurable user interface), a memory 406. The at least one processor 402 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 402 is configured to fetch and execute computer-readable instructions stored in the memory 406.The I/O interface404 may include a variety of software and hardware interfaces, for example, a web interface, and the like. The I/O interface 404 may allow the delegatee 106 to communicate with other devices such as the proxy device 102 and the delegator 104. The I/O interface 404 may facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, Local Area network (LAN), cable, etc., and wireless networks, such as Wireless LAN, cellular, Device to Device (D2D) communication network, Wi-Fi networks and so on. The modules 408 include routines, programs, objects, components, data structures, and so on, which perform particular tasks, functions or implement particular abstract data types. In one implementation, the modules 408 may include a conditional PRS module 410. The conditional PRS module 410 can be configured to generate the common string using the Setup(k) function for the parameter k of the conditional PRS system 100. Further, the conditional PRS module 410 can be configured to generate the delegatee public key (pkDelegatee) and the delegatee secret key (skDelegatee) using the KeyGen () function. Further, the conditional PRS module 410 can be configured to communicate with the proxy device 102 and the delegator 104 through the protocol of the ReKey(skDelegator,pkDelegatee,C) function to enable generation of the conditional RSK. Further, the conditional PRS module 410 can be configured to send signed messages, S= sign (skDelegatee,condition,message), with the delegatee signature to the proxy device 102 and request the proxy device to forward the messages to the one or more entities 1081-108n by translating the delegatee signature to the re-signature, which is the delegator signature.
The modules 408 may include programs or coded instructions that supplement applications and functions of the delegatee 106. The data 412, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules 408. Further, the names of the other components and modules of the delegatee 106 are illustrative and need not be construed as a limitation.
FIG. 5 is a flow diagram illustrating a method 500 for delegation of authentication using the conditional PRS scheme for in the conditional PRS system, according to embodiments as disclosed herein. At step 502, the method 500 includes allowing the re-signature module 210 of the proxy device 102 to receive the conditional RSK that is generated by the delegator 104 using the ReKey function for the ST condition. The ST condition is defined by the delegator 104 who delegates authentication to the delegatee 106 for the ST condition. This ST condition is to be verified by the proxy device 102 for translating the delegatee signature for the message to the re-signature for the message. The conditional RSK is generated using the delegator secret key from the delegator 104, the delegatee public key from the delegatee 106 and the ST condition defined by the delegator 104 in accordance with the interactive protocol among the delegator 104, the delegatee 106 and the proxy device 102. The conditional RSK is the unidirectional key for translating the delegatee signature to the re-signature held secret only with the proxy device 102.
Once the proxy device has the conditional RSK key and the ST condition, then at step 504, the method 500 includes allowing the re-signature module 210 to receive the message from the delegatee 106. The message from the delegatee 106 is signed with the delegatee secret key and is appended with a condition, wherein the condition is to be verified with the ST condition. At step 506, the method 500 includes allowing the re-signature module 210 to verify the condition received with the message to the ST condition defined by the delegator 104. At step 508, the method 500 includes allowing the re-signature module 210 to translate the delegatee signature for the message to the re-signature (S to S’) using the conditional RSK when the condition received in the message verifies with the ST condition. At step 510, the method 500 includes allowing the re-signature module 210 to send the message signed with the re-signature to one or more entities 1081-108n of the conditional PRS system 100 destined to receive the message. The re-signature is identical to delegator signature and can be easily verified by one or more entities 1081 to 108n using the delegator signature. The conditional PRS system using the conditional PRS scheme is explained in conjunction with the use case example in FIG.6 describing the VANET based on the conditional PRS scheme proposed by the method 500.
The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.
FIGs. 6a and 6b is an example conditional PRS system implemented in Vehicle Ad-hoc Networks (VANETs) that utilizes the conditional PRS scheme, according to embodiments as disclosed herein. Figure 6a and 6b show the block diagram of Vehicle Public Key Infrastructure (VPKI) system 614 along with other entities interacting with the VPKI system 614 such as Road Side Units (RSUs) and vehicles. A country’s root Certification Authority (CA) 612 (as shown in FIG 6b) has a secret key SKCA. Since there may be many regions in the country, each region has a regional CA such as CA-region A (602), CA-region B (608), CA-region C (610) and so on as shown in FIG 6b. This enables distribution of job and convenience within the VPKI system 614. Each regional CA has few Road Side Units (RSUs) associated with them. The RSUs have their own secret keys. For example, RSUj 604 which comes under region B has a secret key SKRSUj. The regional CA-region B (608) functioning as proxy device 102 has a conditional RSK generated using the ST condition provided by the root CA 612 (here, functioning as the delegator 104), which converts root RSUs signature (which is functioning as the delegatee 106 here) into root CAs 612 (here, functioning as the delegator) signature if the ST condition defined by the root CAs 612 holds good. When a vehicle 606 enters region B from Region A, it is required to pass through the RSUj 604. The vehicle 606 comprises an on-board unit (OBU) and a trusted platform module (TPM). The RSUj 604 checks the vehicle 606 and signs on the vehicle’s credentials and the condition to cross the border, to grant entry. But since there are multiple RSUs for a single region, the signature of the RSUj should be converted to that of the root CA’s 612 signature. Hence the authenticity to the entry of all vehicles in a given area can be verified using the root CA’s 612 public key. The regional CAs, such CA-region A 602, CA region B 608, hold the ST condition for which the signature can be converted. The delegator (root CA 612) can impose the ST condition such as mentioning the kind or type of vehicles that can pass through the specific RSU. Hence the regional CA (proxy device 102) can convert signatures only if the STcondition is satisfied on receiving message from the RSUj 604 corresponding to the vehicle 606. These re-signature keys with embedded STcondition can be defined on the fly as and when new policies may be introduced.
Figure 6b explains how the vehicle 606 provides the credentials and conditions to the RSUj 604 and RSUj 604 signs them. Further, the signed credentials are sent by the RSUj 604 to the regional CA of the corresponding region, who converts it into the sign of root CA 612 and sends it back to the RSUj to verify and proceed with trafficking. This conditional PRS based scheme implemented in the VPKI system 614 is useful for practical real time applications. In an application, where entry of vehicles not possessing insurance or not cleared taxes for a specific region (STcondition) can be restricted. In another application tourist vehicles can be authenticated based on conditions in a foreign region using this mechanism. Another application, can be to allow access to Very Important Person (VIP) cars or cars, which belong to that region. This application hence can be used as substitute for access control lists and hence having limited effect on storage in the infrastructure and distributed load on the root CA 612.
The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in FIG. 1 through FIG. 6 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
,CLAIMS:STATEMENT OF CLAIMS
We claim:
1. A method for delegation of authentication in a conditional Proxy Re-Signature (PRS) system, the method comprising:
receiving, by a proxy device, a message from a delegatee, wherein the message is signed with a delegatee secret key and appended with a condition;
verifying, by the proxy device, the condition received with the message to a Signature Translation (ST) condition defined by a delegator for translating a delegatee signature for the message to a re-signature for the message; and
translating, by the proxy device, the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) generated for the ST condition when the condition received in the message verifies with the ST condition.
2. The method as claimed in claim 1, wherein the method comprises sending the message with the re-signature to at least one entity of the conditional PRS system destined to receive the message, wherein the re-signature is a delegator signature of the delegator that is verified by the at least one entity using the delegator signature.
3. The method as claimed in claim 1, wherein the conditional RSK for the ST condition is received from the delegator along with the ST condition, wherein the conditional RSK is generated using at least one of a delegator secret key from the delegator, a delegatee public key from the delegatee and the ST condition in accordance with a protocol, wherein the conditional RSK is an unidirectional key for translating the delegatee signature to the re-signature.
4. A conditional Proxy Re-Signature (PRS) system for delegation of authentication ,wherein the conditional PRS system comprises a proxy device, a delegator, a delegatee and at least one entity, wherein the proxy device is configured to:
receive a message from the delegatee, wherein the message is signed with a delegatee secret key and appended with a condition;
verify the condition received with the message to a Signature Translation (ST) condition defined by the delegator for translating a delegatee signature for the message to a re-signature for the message; and
translate the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) generated for the ST condition when the condition received in the message verifies with the ST condition.
5. The conditional PRS system as claimed in claim 4, wherein the proxy device is configured to send the message with the re-signature to at least one entity of the conditional PRS system destined to receive the message, wherein the re-signature is a delegator signature of the delegator that is verified by the at least one entity using the delegator signature.
6. The conditional PRS system as claimed in claim 4, wherein the delegator is configured to generate and send the conditional RSK to the proxy device, wherein the conditional RSK is generated using at least one of a delegator secret key from the delegator, a delegatee public key from the delegatee and the ST condition in accordance with a protocol, wherein the conditional RSK is an unidirectional key for translating the delegatee signature to the re-signature.
7. A proxy device for delegation of authentication in a conditional Proxy Re-Signature (PRS) system, wherein the proxy device comprises a re-signature module, wherein the re-signature module is configured to:
receive a message from a delegatee, wherein the message is signed with a delegatee secret key and appended with a condition;
verify the condition received with the message to a Signature Translation (ST) condition defined by a delegator for translating a delegatee signature for the message to a re-signature for the message; and
translate, by the proxy device, the delegatee signature for the message to the re-signature using a conditional Re-Signature Key (RSK) generated for the ST condition when the condition received in the message verifies with the ST condition.
8. The proxy device as claimed in claim 7, wherein the re-signature module is configured to send the message with the re-signature to at least one entity of the conditional PRS system destined to receive the message, wherein the re-signature is a delegator signature that is verified by the at least one entity using the delegator signature.
9. The proxy device as claimed in claim 7, wherein the conditional RSK and the ST condition is received by the proxy device from the delegator, wherein the conditional RSK is generated by the delegator using at least one of a delegator secret key from the delegator, a delegatee public key from the delegatee and the ST condition in accordance with a protocol, wherein the conditional RSK is an unidirectional key for translating the delegatee signature to the re-signature.
Dated this 11th February, 2016
Signature:
Name of the Signatory: Dr. Kalyan Chakravarthy