A Two-Factor RSA-Based Robust Authentication System for Multiserver Environments

,


Introduction
Nowadays, network technologies and the online applications are rapidly growing; the Internet users are accessing online services to make their life more comfortable over Internet.When accessing a remote server, a session key should be negotiated between user and remote server, which would be used to encrypt the confidential messages.In this regard, two-factor authentication protocols using smart-card and password are widely used and designing a robust and efficient two-factor authentication protocol is a critical task.The concept of client-server communication over insecure networks has been introduced for single server environment, and many researchers have proposed numerous authentication protocols [1][2][3] using hash function [4][5][6], RSA cryptosystem [7][8][9], elliptic curve [10], chaotic map [11,12], and bilinear pairing [13].However, these protocols are unsuitable for multiserver communications.For this purpose, lots of authentication protocols [13][14][15][16][17] have been put forward for multiserver architecture.In multiserver communications, there are three entities such as a user, a registration center, and a number of application servers.In this environment, all the application servers and users registered themselves to the registration center.All of these application servers are responsible for providing required services to the users.An architecture of the multiserver communication is given in Figure 1.User anonymity [18,19] is one of the security issues in user authentication protocol, where user's identity should be kept secret from the adversary.There are several application areas such as banking, medical system [7,10], and wireless sensor network [20], where the authorized users want to keep their identity secret from an adversary; that is, the adversary is unable to extract or guess user's original identity from the login and authentication messages.In addition to that, the mutual authentication is another important security aspect, where client and server both can verify each other to avoid man-in-the-middle attack.As the adversary can also act as server, so verifying at the server end is also important.Like mutual authentication, protection of low-entropy information such as identity and password from guessing attack is very imperative.Furthermore, the insider attack is also difficult to protect since a person who is managing the registration center may misuse users' confidential information such as password.So, the protection of such kind of attack is also essential.As we know the public messages of any authentication protocol are transmitted via open channels, and thus an adversary may intercept, drop, modify, and reroute the captured messages.Thus, the adversary can try to impersonate either the user or the remote server.In this regard, mutual authentication [18,19] between the participants is most important security aspect.Another objective of any clientserver authentication protocol is to negotiate a session key between entities.Since both the participants negotiate their session key, whether the session keys computed by the both entities are equal or not should be checked.In order to perform this, a session key verification property [21] should be involved in the protocol.
1.1.Literature Reviews.In the literature, numerous multiserver authentication protocols are designed to achieve strong security as well as lower complexities.In 2009, Liao and wang [22] put forward a multiserver authentication protocol; however, Chen et al. [23] showed that the protocol in [22] suffers from forward secrecy problem.Further, Hsiang and Shih [24] demonstrated that the protocol in [22] cannot defy some common attacks [13], and then they enhanced it to remedy the identified weaknesses.Lee et al. [25] designed an enhanced and efficient multiserver authentication protocol after pointing out the security weakness of the protocol in [24].Subsequently, Troung et al. [26] illustrated that the protocol in [24] cannot resist smart-card stolen and user impersonation attacks.To vanquish these loopholes, the authors put forward another multiserver authentication protocol and showed that it is secure against common attacks.Moreover, Sood et al. [15] observed different security weaknesses of the protocol in [24] and then designed a multiserver authentication protocol.In 2012, Li et al. [17] showed that the protocol in [15] cannot withstand smart-card stolen attack and subsequently put forward a new protocol.Currently, Pippal et al. [14] designed a secure smart-card based user authentication protocol and showed that their protocol is robust against known attacks.Unfortunately, He et al. [27] demonstrated that the protocol in [14] is not secure against impersonation attack, offline password guessing attack, insider attack, and server spoofing attack.Also, Yeh [16] demonstrated that the protocol in [14] is not secure against some common attacks.More recently, Hsieh and Leu [28] demonstrated that Liao and Hsiao's protocol [29] could not give full security requirements and then devised an efficient protocol using bilinear pairing.In 2015, Amin and Biswas [13] showed that the protocol in [28] is insecure against offline password guessing attack, server masquerading attack, and user anonymity problem.Additionally, they described that the password change facility of this protocol is not user-friendly.To overcome these security vulnerabilities, Amin and Biswas [13] devised user authentication and session key agreement protocol using smart-card and bilinear pairing.In the same year, Giri et al. [8] proposed a robust authentication protocol using RSA and claimed that it is strongly protected against security vulnerabilities.But, Amin and Biswas [7] highlighted that the protocol in [8] is not secure against several security attacks.Further, they proposed a new protocol to overcome the security weaknesses.In 2016, Sutrala et al. [30] show that the protocol in [7] is not secure and also proposed an improved protocol.Similarly, the authors in [31] demonstrated security attacks of the protocol in [7] and proposed a new RSA-based authentication protocol.

Contributions.
This article claims the following contributions.
(i) We have pointed out that all the existing RSA-based multiserver protocols include high computation cost and are insecure against known attacks.
(ii) The main contribution of this article is the design and analysis of a lightweight and robust authentication protocol for multiserver environments.
(iii) The proposed protocol is analyzed using the AVISPA S/W and its results showed that our protocol is secure.
(iv) We proved that our protocol is completely protected against known security threats.Further, it solves the problem of anonymity issue.
(v) We show that the performance of our protocol is better in terms of computation and communication overheads.
1.3.Organization of the Article.Section 2 discusses our authentication protocol for multiserver architecture.The concrete security discussion of our protocol appears in Section 3.
The authentication correctness of our protocol using BAN logic is shown in Section 4. The simulation results of our protocol using AVISPA S/W are discussed in Section 5.The comprehensive performance measurement of our protocol and comparative results with other protocols appear in Section 6.We have provided the conclusion with some remarks and future scope in Section 7.

Proposed Authentication Protocol
Based on RSA cryptosystem, this section introduces a twofactor multiserver authentication protocol using password and smart-card.Our authentication protocol includes initialization phase, registration phase for application server AS  and user   , login phase, verification phase, and password change phase.We present a list of symbols used throughout this article in the Notations.

Initialization
Phase.This phase is executed by the RC to initialize the whole system.Accordingly, RC determines two large prime numbers  and  (each of them at least 1024 bits), computes  =  × , and further determines a generator  ∈  *  .RC keeps (, ) as secrets and publishes  as public value.RC further selects a cryptographic hash function ℎ(⋅): {0, 1} * → {0, 1}  , where {0, 1} * represents arbitrary binary string and {0, 1}  is a fixed-length  binary string.

Application Server Registration
Phase.The main objective of AS  is to provide remote services to   on demand through insecure communication.In order to provide remote services, all AS  must execute registration phase to the trusted RC.During registration, RC and AS  perform the operations as given below.
Step 1. AS  first selects his/her identity ID  and submits it to RC through a secure channel.
Step 3. RC maintains a table RCT that includes ⟨ID  ,   , (  ⊕ )⟩ and keeps it securely.Finally, RC sends   to AS  securely.
We further depict the registration phase of application server of the proposed protocol in Figure 2.

User Registration Phase.
To register with RC,   performs the tasks as explained below.
Step 1.   determines his/her identity ID  together with password PW  and sends ⟨ID  ,   ⟩ to RC over a secure channel, where   = ℎ(ID  ‖ PW  ).
Step 3.After preparing the smart-card, RC sends it to   over secure channel or in person.Further we demonstrate the user registration phase of our protocol in Figure 3.

Login Phase.
At the time of enjoying remote services,   takes initiation and executes this phase.The following operations are performed in this phase.
Step 1.   inserts the smart-card and enters ⟨ID  , PW  ⟩ to the terminal on request.Then, the terminal computes Step 2. The terminal now produces a random number   and calculates  1 = ℎ( *  ‖   ) and  2 = ℎ( *  ) ⊕   and then sends ⟨ 1 ,  2 ,   , ID  ⟩ to RC using an insecure channel.
Further we provide description of login phase of the proposed protocol in Figure 4.

Verification Phase.
This phase achieves a session key agreement between   and AS  with the help of RC over insecure communication.All the operations performed by RC,   , and AS  are discussed now.
Step 1.After getting login message ⟨ 1 ,  2 ,   , ID  ⟩, RC first decrypts   using its own secret key  and then further computes Then RC checks whether   1 matches with  1 .If the condition holds,   is verified by RC.
Step 2. RC extracts   and the public key   and then computes  3 =   ⊕ ID  .Finally, RC sends ⟨  ,  3 ⟩ to   via insecure channel.
Step 4. After receiving  5 , AS  first decrypts  5 using its private key   and according to RSA cryptosystem, AS  obtains ⟨ID  ,   ,  4 ⟩.Then AS  computes    = ℎ(  ‖   ) and   4 = ℎ(ID  ‖   ‖    ‖ ID  ) and then checks whether   4 matches with  4 .If such condition is incorrect, AS  terminates the connection or else authenticates   .
Further we provide the description of verification phase of our protocol in Figure 5.

Password Change Phase.
In password-based remote user authentication protocol, user's password is one of the most sensitive information pieces and must be changed whenever required.Therefore, password change phase must be rendered to the registered user.This phase requires the following actions to change the password.
Step 1.   inserts the smart-card and enters old ⟨ID  , PW  ⟩ to the terminal on request.Then, the terminal computes  *  = ℎ(ID Further we explained the our password change phase in Figure 6.

Discussion about the Security
This section measures security strength of our protocol by analyzing several security attacks.Generally, password-based authentication protocol suffers from different attacks.The authentication protocol must resist the known attacks and achieve mutual authentication, session key verification along with login, and password change phase efficiently.Here, we analyze that our protocol can defy all the relevant security attacks.In this regard, we define some valid assumptions [2,10,20] as follows.
Definition 1.An adversary A has the capabilities for retrieving smart-card information using power consumption monitoring method [34,35].For instance, if A gets the smart-card, he/she has the capability of finding the confidential data from it.
Definition 2. All messages produced by the protocol during execution are sent via insecure communication such as Internet.Therefore, A intercepts, deletes, modifies, reroutes, and resends the transmitted message.It is worth noting that A cannot intercept any information from the secure network [10].Definition 3. A knows execution of the protocol; that is, the protocol is public.Additionally, A may behave like legitimate user or client.Definition 4. We considered that the authorized user selects dictionary word as password and identity.It is noted that A is unable to guess password and identity in polynomial time.If   = ℎ(ID  ‖ PW  ) is known to A, then it is hard to verify guessed password and identity using   in polynomial time [20].
Figure 6: Password update phase of our protocol.
Definition 5. We considered that the random nonce and secret key size are significantly large (parameter with high entropy).Therefore, A is unable to guess the information within polynomial time. mod ,   =   ⊕   ,   = ℎ(  ‖   ), and   = ENC  (ID  ).Note that A cannot compute any confidential information of   or AS  using   .Further,   and   are protected by the hash function and symmetric key encryption algorithm, respectively.Therefore, the extraction of secure information by A is infeasible and the protocol resists smart-card stolen attack.

Theorem 9. Our multiserver authentication protocol can defy the offline identity guessing attack.
Proof.As per Theorem 8, it is clear that A has no advantage to found confidential information from the lost/stolen smartcard of any legal user.In this attack, we further elaborated whether A can guess user's identity using intercepted public messages.We supposed that A intercepts the login messages ⟨ 1 ,  2 ,   , ID  ⟩, ⟨  ,  3 ⟩, and ⟨ 5 ,  6 ,   ⟩, where )   mod ,   =   ⊕   , and  6 = ℎ(SK  ‖   ‖ ID  ).Note that A cannot guess ID  using   without knowing the secret key  of RC.Further, A cannot guess ID  from  3 without   .If A wants to verify the guessed identity using  *  and  3 , the probability would be approximately 1/2 6+1024 and 1/2 6+128 , respectively, where length of  is 1024 bits.The value of  5 is transmitted as ciphertext, and therefore, it is also infeasible to extract information without the private key   of AS  .Hence, the proposed authentication protocol can defy this type of offline identity guessing attack.

Theorem 10. Our multiserver authentication protocol can defy the offline password guessing attack.
Proof.Similar to Theorem 9, A may attempt to guess PW  of   in offline mode.We described in Theorem 8 that A cannot extract or guess   's password PW  from the smartcard information.In addition, the public messages are also independent of   's PW  .As a result, A has no way to guess   's password in offline mode.

Theorem 11. Our multiserver authentication protocol can defy the insider attack.
Proof.As mentioned in [7,10], if the insider person A of RC or AS  gets   's password PW  by some means, she/he can attempt to login different accounts of   .Thus, the protection against the insider attack is also an important issue in password-based authentication system.When the registration phase of our protocol is executed,   delivers ID  and   to RC for issuing a smart-card, where   = ℎ(ID i ‖ PW  ).Since   is protected by hash function, A is unable to extract PW  due to one-way behavior of the hash function.

Theorem 12. Our multiserver authentication protocol can defy the user impersonation attack.
Proof.To impersonate   , A has to generate a valid login message that must be authenticated by RC.During the login phase,   generates ⟨ 1 ,  2 ,   , ID  ⟩, where  1 = ℎ( *  ‖   ) and  2 = ℎ( *  ) ⊕   .Note that A can generate the random number   .However, it is very difficult to compute   =  ⋅ID  mod  without knowing ⟨, ID  ⟩ from the known information.Therefore, the protocol resists user impersonation attack.

Theorem 13. Our multiserver authentication protocol can defy the server impersonation attack.
Proof.Resembling Theorem 12, A may attempt to forge the authentication message to AS  .For that, A has to compute another genuine message ⟨ 6 ,   ⟩, which is to be authenticated by   , where   =   ⊕   and  6 = ℎ(SK  ‖   ‖ ID  ).Now, A generates the random number    ( ̸ =   ) and tries to compute the valid   .But, it is infeasible to compute   without knowing   .On the other hand, A cannot compute correct  6 without knowing SK  .Hence, the adversary is unable to launch this attack.

Theorem 14. Our multiserver authentication protocol can defy the session key computation attack.
Proof.The protocol negotiates a session key between   and AS  , which will be used to encrypt the confidential information transmitted over public channel.Our authentication protocol computes the session key SK  = SK  = ℎ(ID  ‖ ID  ‖   ‖   ) and its security depends on the hash function.Note that session key depends on the confidential information ⟨ID  ,   ,   ⟩.We discussed earlier that A is unable to compute these pieces of information.Hence, A is unable to calculate the session key of our protocol.

Theorem 15. Our multiserver authentication protocol can defy the known session specific temporary information attack.
Proof.It is assumed that short-term information used in the protocol is known to A. However, A could not compute the session key in any session.We assume that A knows   and   tries to compute SK  .Then A needs ID  to compute SK  .We described earlier that the computation of ID  is not feasible by A. Therefore, A cannot launch this attack.

Theorem 16. Our multiserver authentication protocol can defy the stolen verifier attack.
Proof.At the time of application server registration, RC maintains a table called RCT, which includes ⟨ID  ,   , (  ⊕ )⟩.Among these,   is the most confidential parameter used in the proposed protocol.We now supposed that A got RCT by some means and attempted to break the security of the proposed protocol.Note that   is not stored in plaintext form.It is stored as   ⊕  in the table, where  is the secret key of RC.As a result, A cannot compute   without knowing .

Authentication Proof Using BAN Logic
This section addresses the freshness of the exchanged message and the proof of the mutual authentication based on Burrows-Abadi-Needham (BAN) logic [9,13].Being a known security model, BAN logic is required to demonstrate the authentication and secure key distribution protocols.Now, some backgrounds and notations used in BAN logic are given below.
(i) Principals are agents involved in the protocol (usually people or programs).
(ii) Keys are required to encrypt messages symmetrically.
(iii) Public Keys are similar to Keys except they are used in pairs.
(iv) Nonces are message parts that are not repeated.
(v) Timestamps are similar to nonces where they are unlikely to be repeated.
The BAN statements used in this paper that are required to analyze the security of our protocol are listed in the Notations.The logical postulates of the BAN logic are listed in Table 1.
In order to prove the authentication protocol is valid, a list of the following things must be processed: (i) In language of formal logic, idealize our protocol.
(ii) Find out assumptions about the initial state of our protocol.
(iii) In order to deduce new predicates, use production and rules of the logic.
(iv) Use logic to find out beliefs made by parties in our protocol.
To show our protocol is secure, it must satisfy BAN logic based goals as discussed below.
(i) Goal 1: Our protocol is transformed into the idealized form: The discussion made above proves that our protocol correctly achieves the mutual authentication property.

Simulation Results of the Scheme Using AVISPA
We first briefly discuss the concept of the AVISPA and then present simulation results followed by HLPSL code of our protocol.According to literature review, the AVISPA is one of the widely used simulation tools for verifying security correction of the authentication protocol.Many earlier protocols [7,10,20] have been simulated using AVISPA tool.

Description of the AVISPA Tool.
It is well known that AVISPA [37] is known as a tool for formal security verification.AVISPA supports HLPSL (High Level Scheme Specification Language).A general description and pictorial representation of the AVISPA tool can be found in [20,37,38].AVISPA tool supports four different back-ends (OFMC, CL-AtSe, SATMC, and TA4SP) and abstraction based methods that are integrated through HLPSL.We refer to [38] for more details of OFMC, CL-AtSe, SATMC, and TA4SP.During the execution of the tool, HLPSL specification is interpreted into intermediate form (IF) by hlpsl2if translator where IF is lower-level language and directly read by AVISPA back-ends.
The HLPSL is a role-oriented language where every party plays a role during protocol execution.Every role is free from others, retrieving some initial information through parameters and communicating with other roles by the channels.Intruder is framed using the model [39] with a possibility for intruder as a legitimate role in protocol run.In addition, role system narrates principals, number of sessions, and roles.OUTPUT FORMAT (OF) using the four back-ends is produced, and (OF) after successful execution highlights role user (Ui, RC, ASj: agent, SKey1 : symmetric_key, SKey2 : symmetric_key, H, MUL, SUB: hash_func, Snd, Rcv: channel(dy)) played_by Ui def= local State : nat, IDi, PWi, IDj, N, Ej, Yj: text, Di, Ei, Fi, Ai, Bi, Ci, Ri, M1, M2, M3, M4, M6, Rij, Rj, M5, SKi: message, Inc : hash_func const user_rserver, rserver_aserver, aserver_user, sec1, sec2, sec3, sec4, sec5, sec6: protocol_id the result whether our protocol is safe or not under which condition output is generated.Based on the HLPSL language, we have implemented the role specifications for the user, registration center, and application server in Algorithms 1, 2, and 3, respectively.The role specification for the session, goal, and environment in HLPSL is given in Algorithm 4.

Simulation Results. Algorithms 5 and 6 show the results
on back-ends CL-AtSe and OFMC.Results for both the back-ends confirm that the protocol is SAFE which indicates that the protocol resists passive and active attacks.The proposed protocol achieves the following six properties and two authentication phases that are mentioned below.
(1) Secrecy_of sec 1: PW  is the confidential information and known to   only.(2) Secrecy_of sec 2: the confidential information   is known to ⟨  , AS  , RC⟩ only.
(3) Secrecy_of sec 3: the session key SK  is shared only between   and AS  .

Performance Evaluation and Discussion
This section discusses the performance of the proposed protocol and then compares it with the recently published protocols [14,16,32,33] in terms of computation, smart-card storage, and communication costs.Note that the login and authentication phases are necessary for performing secure communication in each authentication cycle.Therefore, we have considered these phases in comparison.To evaluate the computational cost, this article used the following time complexities.
(i)  ℎ : cost for one-way hash operation (ii)  sym : cost for symmetric key encryption/decryption operation (iii)   : cost for exponentiation operation (iv)   : cost for modular multiplication operation The results obtained in [40]  encryption/decryption, and SHA-1 operation.On these above configurations, execution time (in ms) of such different operations is as follows:  ℎ ≈ 0.0004 ms,  sym ≈ 0.1303 ms,   ≈ 0.0147 ms, and   ≈ 1.8269 ms.
In Tables 2 and 3, we observed that computational cost and execution time of our protocol are lower than the protocols proposed in [14,16] and nearly equal to the protocols in [32,33].Our protocol provides strong security protection against known attacks, such as mutual authentication, user anonymity, session key agreement, efficient login phase, and verification phase, and response time of the protocol is comparatively lesser than other protocols.For better understanding, we give execution cost (ms) comparison of the proposed protocol and the related ones [14,16,32,33] in Figure 7.
In Table 4, smart-card storage cost, communication cost, and total number of message transmissions have been provided.The notation 160× *  indicates that smart-card storage capacity is dependent on the total number of application servers.Therefore, the limitation of the protocols [14,16,32] is that the number of application servers is restricted owing to low capacity of smart-card.Note that smart-card storage cost does not increase with the number of application servers in the protocol [33] and our protocol.The proposed protocol requires less storage costs for the smart-card compared to the protocols proposed in [14,16,32,33].In our protocol, we provide session key verification property and to achieve it, the protocol takes extra single message exchange in comparison with the protocols [14,16,32,33].Note that the protocols [14,16,32,33] do not provide the session key verification  property.In Table 4, we also noticed that the total number of bits transmission of our protocol is lesser than related protocols.

Conclusion and Future Scope
This article presents a flexible and cost-effective RSA-based multiserver authentication protocol to perform secure mutual authentication over any insecure channel with user and application server.We have then proved informally that our protocol can defy different cryptographic attacks.Moreover, the security of the mutual authentication and the freshness of the  models.We have then shown that the performance of our protocol is more effective than the existing protocols in terms of complexities.Our protocol is not only robust, but also flexible since it has user-friendly password change phase.In recent times, cloud computing is also applied to the environment of mobile communication.However, the Session key is used in the current session.

Figure 2 :
Figure 2: Application server registration phase of our protocol.

Figure 3 :
Figure 3: User registration phase of our protocol.

Figure 5 :
Figure 5: Verification phase of our protocol.
authenticates AS  and session key generated by   and AS  is verified.
and   6 = ℎ(SK  ‖    ‖ ID  ) and checks whether   6 =? 6 holds.If the condition holds, ) and checks whether  *  matches with   .If the condition is correct, it implies that (ID *  = ID  ) and (PW *  = PW  ).After successfully verifying ⟨ID  , PW  ⟩, the smartcard made request to the   for a new password.Then   enters a fresh password PW   and then the smart-card computes    = ℎ(ID  ‖ PW   ),    = ID *  ‖ PW *  ),  *  = ID *

Table 1 :
Logical postulates of BAN logic.If principal  believes  is shared with  and sees ⟨⟩  , then  believes  once said .If  believes  is fresh, then  believes the freshness of (, ).If principal  believes  and , then  believes (, ).If  believes  is fresh and the principal  once sent , then  believes that  believes .If the principal believes that  has jurisdiction over  and  believes , then  believes that  is true.If  believes session key is fresh and  and  believe , which are the necessary parameters of session key, then  believes that (s)he shares session key  with .
) Secrecy_of sec 5: the confidential information  and  pieces are only known to RC. (6) secrecy_of sec 6: the random numbers ⟨  ,   ⟩ are known to ⟨AS  ,   ⟩ only.(7) authentication_on alice_server_Ri:   produces a random nonce   , and if AS  gets it secretly, then AS  authenticates   .(8) authentication_on server_alice_Rj:   authenticates AS  based on the random number   .
have executed various cryptographic operations using MIRACL C/C++ Library.It requires Windows 7 with 32-bit OS, Visual C++ 2008, 1024bit cyclic group, 160-bit prime field   , AES for symmetric Role specification for the goal, session, and environment of our protocol in HLPSL.

Table 3 :
Execution time (ms) comparison of our protocol with other protocols.
session key have been established based on BAN logic model, and AVISPA simulation results claim that proposed protocol is SAFE in CL-AtSe and OFMC CL-AtSe back-end result of the proposed protocol.

Table 4 :
Communication and storage costs of our protocol and others.computation and storage capabilities of mobile devices are very limited.Therefore an attempt can be made to design a provably secure and lightweight multiserver authentication protocol for mobile cloud computing environments.Identity of   ID  : Identity of AS    : R a n d o mn u m b e rs e l e c t e di nl o g i n phase by the     : R a n d o mn u m b e rs e l e c t e di n authentication phase by the AS  : S e c r e tk e yo fR C , : Two different large prime numbers   : P u b l i ck e yo fA S    : P r i v a t ek e yo fA S  SK  : Session key shared between   and AS  ℎ(⋅): Ro p e r a t i o n ENC  (): Symmetric key encryption using key  of message .(ii) BAN Statements Used in This Paper  |≡ :  believes , or  would be entitled to believe .In particular,  can take  as true  ⊲ :  sees . has received some message  and is capable of reading and repeating it (seeing rule)  |∼ :  once said .  at some time sent a message including the statement .It is not known whether this is a replay, though it is known that  believed  when he sent it  ⇒ :  has jurisdiction over .The principal  is an authority on  and should be trusted on this matter ♯(): Message is fresh (, ): Formula  or  is one part of the formulae (, ) ⟨⟩  : Formula is combined with the formulae  {}  : Formula is encrypted under the key  ()  : Formula is hashed with the key    ← → : Principals  and  communicate via shared key   Formula  is a secret only known to  and and possibly to principals trusted by them : → :Principal has  as its public key SK: