[0104] Example 1
[0105] In this embodiment, the identity-based two-party key agreement protocol is implemented in the form of a website, and the security of the protocol is demonstrated on the website. The details are as follows:
[0106] (1) A new identity-based two-party key agreement protocol.
[0107] The algorithm mainly involved in this protocol is an identity-based key agreement scheme. The identity-based key agreement scheme is composed of three phases: system establishment, key extraction (user’s public and private keys), and key agreement. This system is based on Shim (Shim K. Efficient ID-based authenticated key agreement protocol). Based on Weilpairing.Electronics Letters,2003,39(8):653-654.), the improvement of the identity-based key agreement scheme, the schematic diagram of the identity-based key agreement system is as follows figure 1 , The specific steps of the whole process are as follows:
[0108] (1) System establishment: public system parameters: {G 1 ,G T ,p,e,P,P pub ,H 1 ,H 2 }, keep the master private key s;
[0109] Among them, G 1 : Is the additive cyclic group generated by P;
[0110] G T : As with G 1 Multiplicative cyclic groups of the same order;
[0111] e:G 1 ×G 1 →G T Is a bilinear mapping;
[0112] H 1 :{0,1} * →G 1 For a safe Hash function;
[0113] H 2 : Is the key extraction function;
[0114] System master private key randomly selected for PKG; P pub =sP: is the system master public key;
[0115] (2) Key extraction: given the identity ID of a user U U , PKG calculates the user’s private key S U =sQ U , Where Q U =H 1 (ID U ) Is the public key of the user. The public and private keys of both parties A and B of the key negotiation here are calculated respectively;
[0116] Where ID U : Represents the identity used for U;
[0117] S U : Represents the private key of user U, S U =sQ U;
[0118] Q U : Represents the public key of user U, Q U =H 1 (ID U );
[0119] (3) Key agreement: A and B are selected randomly Calculate the respective temporary session key T A =aP,T B =bP, and send the value generated by each to the other party; A calculates h=aT B ,K AB =e(aP pub +S A ,T B +Q B ), similarly, B calculates h=bT A ,K BA =e(bP pub +S B ,T A +Q A ), the final shared key is H 2 (h,K AB );
[0120] Where T A : Is Alice's temporary session key, T A =aP, where
[0121] T B : Is Bob's temporary session key, T B = BP, where
[0122] K AB : The unhashed session key calculated by Alice, K AB =e(aP pub +S A ,T B +Q B );
[0123] K BA : The unhashed session key calculated for Bob, K BA =e(bP pub +S B ,T A +Q A );
[0124] h: Temporary session factor to prevent known key attacks, h=aT B , H=bT A.
[0125] (2) The above protocol is completely grafted to the network platform based on the Java language springMVC as the framework, and the main implementation codes for implementing the protocol are as follows:
[0126] The system establishment phase code is as follows:
[0127] protected Element s,a,b,P,Ppub,SA,QA,SB,QB,TA,TB,KA,KB,hA,hB,K;
[0128] protected Field G1, Zr;
[0129] protected Pairing pairing;
[0130] @RequestMapping("users/keys/buildSystem.json")
[0131] public void buildSystem(){
[0132] System.out.println("Start buildSystem");
[0133] init();
[0134] s=Zr.newRandomElement().getImmutable();//Generate the master private key s randomly
[0135] P=G1.newRandomElement().getImmutable();//Generate generator P of G1
[0136] Ppub=P.mulZn(s);//calculation Ppub =sP, pay attention to the order, generate the master public key Ppub.
[0137] }
[0138] The key extraction phase code is as follows:
[0139] @RequestMapping(value="users/keys/extractSecretKeyOf{username}",
[0140] method={RequestMethod.GET,RequestMethod.POST})
[0141] public@ResponseBody List HashMap getSecretKey(@PathVariable("username")String username){
[0142] QA=pairing.getG1().newElement().setFromHash(username.getBytes(),
[0143] 0,username.length()).getImmutable();//Determine the public key generated by user U from the hash value IDu of length 3 Qa , Generate the public key of user U.
[0144] SA=QA.mulZn(s).getImmutable(); //Generate user U's private key.
[0145] List HashMap listone= new ArrayList();
[0146] HashMap newsMap=new HashMap ();
[0147] newsMap.put("P",SA.toString());
[0148] listone.add(newsMap);
[0149] return listone;
[0150] }
[0151] The code for calculating the final session key is as follows:
[0152] public@ResponseBody List HashMap createKA(){
[0153] hA=TB.mulZn(a);
[0154] KA=pairing.pairing((Ppub.mulZn(a)).mul(SA),TB.mul(QB))
[0155] List HashMap listone= new ArrayList();
[0156] HashMap newsMap=new HashMap ();
[0157] newsMap.put("P",SHA((KA.toString()+hA.toString()),"SHA-256"));
[0158] listone.add(newsMap);
[0159] return listone;
[0160] }
[0161] (3) The attack demonstration system of the scheme is provided on the network platform:
[0162] In the initial interface, click the buttons of different attack types to demonstrate different attacks. The specific steps are as follows:
[0163] Step 1: Click the corresponding attack demonstration button (for example, forward security);
[0164] The second step: the two parties who negotiate the key log in;
[0165] The third step: According to the corresponding attack type, at different stages of key negotiation, the adversary starts to intervene in the attack and generate a "session key" of the adversary;
[0166] Step 4: Compare the user-generated session key and the adversary’s "session key" to determine whether the attack is successful;
[0167] Finally exit the system.
[0168] The specific attack demonstration flowchart is as follows figure 2 , This solution has good security and can resist a variety of attacks, including the forward security, known key attack, and key compromise counterfeit attacks demonstrated in this work.
[0169] Compared with the traditional certificate-based public key cryptosystem, the identity-based public key cryptosystem directly uses the user’s identity as the public key such as image 3 As shown, certificates and related operations are not required, which simplifies the use and management of public keys.
[0170] In the key agreement process, three participants are involved, including the system administrator admin, and the two parties who negotiate the key (for the convenience of description, here are respectively A and B)
[0171] After successfully accepting the above login, it jumps to the user negotiation page, and the two parties begin key negotiation. Figure 4 ,Specific steps are as follows:
[0172] Step 1: The system administrator admin logs in and clicks the buildsystem button to clear the historical data in the Java container;
[0173] Step 2: The users of the two parties who will conduct key negotiation log in on their own devices respectively, and select the person who will share the key in the user list;
[0174] The third step: key agreement,
[0175] (1) One party acts as the initiating key agreement party (A) initiates a request to the server, clicks the extract secretkey button to generate its own private key, and the operation of B is the same as that of A;
[0176] (2) A clicks the computeT button to calculate the temporary session key TA, and B operates the same as A to generate TB;
[0177] (3) A clicks the createK button to generate the final session key negotiated by A and B, and B performs the same operation;
[0178] Step 4: Verify that the same session key is generated, and exit safely.
[0179] 1 System implementation steps process
[0180] Run each functional module to get the following effect diagram:
[0181] Key negotiation stage: Take the negotiation between Alice and Bob as an example, Figure 5 It is the flow chart of the key negotiation stage, where (a) is the interface diagram of the clear historical data stage, (b) is the interface diagram of Alice in the negotiated key interface after the user successfully logs in, (c) is the negotiated key after the user successfully logs in Bob's interface diagram in the key interface.
[0182] Image 6 It is the interface diagram of generating the user's private key in a negotiation, where (a) is the interface diagram of generating the private key of user Alice in a negotiation, and (b) is the interface diagram of generating the private key of user Bob in a negotiation.
[0183] Figure 7 It is a temporary session key generation interface diagram, in which (a) is Alice's temporary session key generation interface diagram, (b) is Bob's temporary session key generation interface diagram.
[0184] Figure 8 It is the interface diagram of negotiated key generation. (a) is the interface diagram of Alice negotiated key generation, and (b) is the interface diagram of Bob negotiated key generation interface.
[0185] 2 System implementation attack demonstration process
[0186] 1. Enter the system administrator login account admin and password 123456 to jump to the administrator function interface such as Picture 9 , The administrator can clear the historical data in the Java container by clicking the buildsystem button to start a new key negotiation.
[0187] 2. In the negotiation phase (here, take user Alice as an example), enter the user account Alice and password 1990, and then jump to Alice's user key negotiation page as Picture 10 , Click to select the party (such as Bob) that will perform key negotiation. A key negotiation between the two will be generated in the corresponding private key, temporary session key, and shared key fields;
[0188] 3. Key attack. This work has designed three attack demonstrations: forward security, known key attack, and key compromise counterfeiting. The following three attack demonstration results are shown as follows Picture 11 (a)~(c), Picture 12 (a)~(b), Figure 13 (a)~(b).
[0189] Forward security, the adversary can get the private keys SA and SB of Alice and Bob, but there is no master key s. In this case, the adversary will use the key derivation function to randomly output a result at the end, such as Picture 11 (a), Picture 11 In (b), Alice and Bob get the same session key, and the session key obtained by the adversary is obviously different from the former, which means that the attack failed. This is because the adversary cannot calculate e(P, P) abs.
[0190] Combine Picture 12 (a)~(b), for known key attacks, the server will randomly select new random numbers a and b for each negotiation, so the temporary session key generated each time is different, resulting in a shared session secret The keys are different. Even if a malicious adversary obtains the historical session key, it will not threaten future sessions.
[0191] Combine Figure 13 (a)~(b), Alice leaked SA to the adversary in response to key compromise and impersonation, and the adversary selected randomly Calculate TB and send it to Alice. Since the adversary does not know a randomly selected by SB and Alice, e(P, Q B ) as , The program can resist the attack.
