Chapter 4 Proposed Scheme
4.6 The Applications of Communication
desires to communicate with station B in the same network, the STAkey handshake is required if there is no session key shared between station A and B. After that, station A, station B and internal switch(es) obtain the STAKeyA,B which is used for message protection. The message is
encrypted by station A and concatenated with integrity check value (ICV).On the receipt of message, the internal switch search STAKeyA,B in the local storage based on source MAC address. The ICV is verified by the switch using STAKeyA,B. If the verification is valid, the message is sent out without modified. Otherwise, the switch drops the message. After receiving the message, station B decrypt and verify the message using STAKeyA,B.
Figure 4. 9 The application of STAKey communication in LAN
Second, station communication in virtual-LAN is shown in figure 4.10. The sender and the receiver are acted as the same in station communication in LAN. The 802.1Q tunnel is between two connected switches. While the data frame is transmitted from sender and receiver, which are in the same VLAN, the switch A has to insert 802.1Q tag and encrypt it with the receipt message. And then switch B decrypts the message, verifies the message is sent from switch A. Switch B takes off 802.1Q tag and sends out the encrypted message protected by STAKey to receiver. After receiving the message, receiver utilizes the STAKey to decrypt and verify the message.
Figure 4. 10 The application of STAKey communication in VLAN
Third, the broadcast frames in local area network should be protected by the group session key that every station in the same network can access the data. After the member joins the group, they obtain the latest group SAK. The sender encrypts the frames by group SAK, and then the internal switch verifies the integrity and the authenticity of the message. If the verification is valid, the switch forwards the frames without decrypt the message. Until the frames arrived, they are decrypted and verified by the receivers.
Chapter 5
Security Analysis
In this section, we analyze the security requirements of the proposed protocol. Besides, SVO logic [16] is one of the most complete formal semantic analysis systems now widely used by researchers and designers. To confirm the correctness of the proposed protocols, we use SVO logic to prove STAKey handshake protocol and group CAK distribution protocol.
For STAKey handshake protocol, we derive that the session key is shared only between two negotiated stations. For group CAK distribution protocol, we derive that the new join station obtains the new group CAK from key server and the remaining stations shared the group CAK mutually in join and leave operations.
5.1 Analysis of security requirements
The security of the proposed protocols is analyzed with some well known attacks and requirements.
Key secrecy – The delivered keys are generated independently by strong random number generator and distributed with a secure channel. The attacker has to utilize burst force attack to guess Ω(2m) times with overwhelming probability, where m is the bit-length of the key.
Besides, all the auxiliary keys are computed by one-way function with new group key. The one-way function is based on the property of hash function that is irreversible. The probability is negligible under the random oracle model [18], since the attacker tries to guess the correct keys.
Forward secrecy – Forward secrecy assures that a departing or expelled member knows a series of previous group keys cannot identify subsequent group keys. Suppose that now time period is Ti and a departing member left at Tj, where j < i. The departing member owns GKj
but has not corresponding auxiliary key to decrypt GKj+1. Besides, it cannot compute next auxiliary key without GKj+1. Thus, the departing member is unable to obtain any keys in time period Ti. Forward secrecy is ensured.
Backward secrecy –Backward secrecy ensures that an adversary that knows a subset of group keys cannot discover previous group keys. Suppose that a new member joins the group at time Tj. It has no group key and any auxiliary keys at time Tj-1. Thus the new member is unable to guess any previous keys.
Known key security – Known key security refers that if the session key is compromised, it should have no impact on other session keys. Each session key SAKi is generated by strong random number generator. There is no relationship among session keys. The session key SAKi
is unable to derive previous or future session keys.
Replay attack resistance – Our protocols uses message number to prevent the replay attacks.
Since the message numbers of each members are generated independently, attacks by replaying messages of previous sessions will be failed.
Active attack resistance –This attack requires the attacker to be able to transmit message to one or both of the parties, or block the data stream in one or both directions. The attacker has no way to modify the message and compute the correct integrity check value without CAK or SAK. Thus active attack resistance is ensured.
5.2 SVO logic
This section begins with the introduction to the basic inference rules and axioms. And then we use SVO logic to transform our protocol in to the idealized form and have prerequisite hypothesis and security objectives of the protocol. Finally, we analyze the goals based on formal semantic logic. (X ⊃Y)denotes that the current knowledge of X can be
demonstrated to Y. denotes the secret key shared between A and B. denotes the session key shared between A and B.
B
SKA, KA,B
5.2.1 Inference rules and axioms
Two inference rules:
I3 – P received P received P has K
I4 – (P received received
z
z z etric goodness of shared keys
I12 –
5.2.2 Idealization, hypothesis and security objectives of station key dshake protocol
three parties, S into consideration, the protocol is transformed into an idealized form as follows:
z S1 –
z S5 – s:
We have prerequisite hypothesis of the STAKey handshake protocol as follows:
han
z A1 –
The target protocol is idealized as follows:
KS
z G1 – A believes (A←⎯ →K⎯A,B B ∧ A hasKA,B) z G2 – B believes (A←⎯ →K⎯A,B B ∧ B hasKA,B)
z G3 – A believes ((A←⎯ →K⎯A,B B ∧ A hasKA,B)∧ B says(B hasKA,B)) z G4 – B believes ((A←⎯ →K⎯A,B B ∧ B hasKA,B)∧ A says(A hasKA,B))
5.2.3 Proof based on formal semantic logic of station key handshake protocol
Lemma 1. The proposed STAKey handshake protocol provides secure key establishment, i.e. Goals G1 A believes (A←⎯ →K⎯A,B B ∧ A hasKA,B) and G2 B believes (A←⎯ →K⎯A,B B ∧ B hasKA,B) are achieved.
Proof:
By I3 and A5.1, we apply receiving rule to derive
A received (A←⎯ →K⎯A,B B)SKKS,B (statement 1) By I4, A1.1 and (statement 1), we apply comprehending rule to derive
A received A←⎯ →K⎯A,B B (statement 2) By I5, (statement 2) , R1and I13, we apply seeing and having rules to derive
A sees A←⎯ →K⎯A,B B
A believes (A hasKA,B) (statement 3) By I2, A1.1 and (statement 1), we apply source association rule to derive
KS said A←⎯ →K⎯A,B B (statement 4) By I11, A3.1, A2.3 and (statement 4), we apply nonce-verification rule to derive
KS says A←⎯ →K⎯A,B B (statement 5)
By R1 and (statement 5), we derive
A believes KS says A←⎯ →K⎯A,B B (statement 6) By I9 and (statement 6), we apply jurisdiction rule to derive
A believes A←⎯ →K⎯A,B B (statement 7)
By (statement 3) and (statement 7), we derive A believes and A believes (A has ), which Goal G1 is achieved.
B A←⎯ →K⎯A,B
B
KA,
Goal G2 is same as proof of G1. Thus, the goals G1 and G2 are achieved that we know is good key for A and B.
B
KA,
Lemma 2. The proposed STAKey handshake protocol provides key confirmation, i.e.
Goal G3 and G4 are achieved.
Proof:
By A5.2 and I3, we apply receiving rule to derive
A received (MNB,MNA,B hasKA,B)KA,B (statement 8) By Lemma 1. A believes , I2 and (statement 8), we apply source association rule to derive
B A←⎯ →K⎯A,B
B said (MNB,MNA,B hasKA,B) (statement 9) By I11, A2.2 and (statement 9), we apply nonce-verification rule to derive
B says (MNB,MNA,B hasKA,B) (statement 10) By I8 and (statement 10), we apply saying rule to derive
B says (B hasKA,B) (statement 11)
By R1 and (statement 11), we derive
A believes B says (B hasKA,B) (statement 12)
By Lemma 1. and (statement 12), we derive A believes ((A←⎯ →K⎯A,B B∧A hasKA,B)∧ B says(B hasKA,B)), which Goal G3 is achieved.
Goal G4 is same as proof of G2. Thus, the goals G3 and G4 are achieved that we know is the session key shared with only A and B.
B
KA,
5.2.4 Idealization, hypothesis and security objectives of group key distribution protocol
In this section, there are three parts in the proof: A, B and KS. The proof of each pair of the members obtains the good group key is the same as A and B pair achieves the goals.
Idealization:
Take three parties, A, B, and KS into consideration, the protocol is transformed into an idealized form as follows:
z S1 –KS →A:{MNA,MNKS,MNB,(A←⎯ →K⎯G' B)KG1} z S2 –KS →B:{MNB,MNKS,MNA,(A←⎯ →K⎯G' B)KG2} z S3 –A→B:{MNA,MNB,(MNA,A←⎯ →K⎯G' B)KG'} z S4 –B→A:{MNB,MNA,(MNB,A←⎯ →K⎯G' B)KG'}
Hypothesis:
z A7 –
1. A believes A←⎯ →K⎯G1 KS ∧ A hasKG1 2. B believes B←⎯ →K⎯G2 KS ∧ B hasKG2 3. KS believes A←⎯ →K⎯G1 KS
4. KS believes A←⎯ →K⎯G2 KS z A8 –
1. A believes fresh (MNA) 2. B believes fresh (MNB) 3. KS believes fresh (MNKS) z A9 –
1. KS believes fresh (A←⎯ →K⎯G' B) z A10 –
1. A believes KS control A←⎯ →K⎯G' B 2. B believes KS control A←⎯→⎯KG B z A11 –
1. A received {MNA,MNKS,MNB,(A←⎯ →K⎯G' B)KG1}
2. A received {MNB,MNA,(MNB,B hasKG')KG'} z A12 –
1. B received {MNB,MNA,(A←⎯ →K⎯G' B)KG2}
2. B received {MNA,MNB,(MNA,A hasKG')KG'}
Goal:
The target protocol is idealized as follows:
z G5 – A believes (A←⎯ →K⎯G' B∧ A hasKG') z G6 – B believes (A←⎯ →K⎯G' B∧ B hasKG')
z G7 – A believes ((A←⎯ →K⎯G' B∧ A hasKG')∧ B says(B hasKG')) z G8 – B believes ((A←⎯ →K⎯G' B∧ B hasKG')∧ A says(A hasKG'))
5.2.5 Proof based on formal semantic logic of group key distribution protocol
Lemma 3. The proposed group key distribution protocol provides secure key establishment, i.e. Goals G5 A believes (A←⎯ →K⎯G' B ∧ A has ' ) and G6 B believes ( B has ') are achieved.
KG
B
A←⎯ →K⎯G' ∧ KG Proof:
By I3 and A11.1, we apply receiving rule to derive
A received (A←⎯ →K⎯G' B)KG1 (statement 13) By I4, A1.1 and (statement 13), we apply comprehending rule to derive
A received A←⎯ →K⎯G' B (statement 14) By I5, (statement 14) , R1and I13, we apply seeing and having rules to derive
A sees A←⎯ →K⎯G' B
A believes (A hasKG') (statement 15) By I2, A1.1 and (statement 13), we apply source association rule to derive
KS said A←⎯ →K⎯G' B (statement 16) By I11, A9.1 and (statement 16), we apply nonce-verification rule to derive
KS says A←⎯ →K⎯G' B (statement 17) By R1 and (statement 17), we derive
A believes KS says A←⎯ →K⎯G' B (statement 18) By I9 and (statement 18), we apply jurisdiction rule to derive
A believes A←⎯ →K⎯G' B (statement 19)
By (statement 15) and (statement 19), we derive A believes A←⎯ →K⎯G' B and A believes (A
hasKG'), which Goal G5 is achieved.
e as proof of G5. Thus, the goals G5 and G6 are achieved that we know
oposed group key distribution protocol provides key confirmation, i.e.
By 1.2 and I3, we apply receiving rule to derive
received B A B B has G G (statement 20)
a 1. A believes , I2 and (statement 20), we apply source association rule
said B has (statement 21)
1 and (statement 21), we apply nonce-verification rule to derive
says B has (statement 22)
(statement 24)
ays has )), which Goal G7 is achieved.
e as proof of G7. Thus, the goals G7 and G8 are achieved that we know is the group session key shared with A and B.
G' K
is good key for A and B.
Lemma 4. The pr
Goal G5 and G6 are achieved.
,
By I8 and (statement 22), we apply saying rule to derive
B says (B hasKG') (statement 23)
By R1 and (statement 23), we derive elieves B says (B hasKG')
By Lemma 3. and (statement 24), we derive A believes ((A←⎯ →K⎯G' B∧ A hasKG')∧ B s (B
G' K
Chapter 6
Performance Analysis
In this chapter, both the computation and communication cost of NAC will be evaluated. As the results showed, NAC incurs the lowest cost compared with related work.
6.1 Communication Cost of Group key distribution
In this section, we will compare our proposed scheme with other schemes that we mention previously. The comparison divides into two parts: communication cost, and computation cost.
Communication Cost
Join Leave Tree Balance
Unicast Multicast Multicast
LKH log2N+1 log2N 2×logd N No
OFT log2N+1 log2 N log2N No
Proposed log2N+1 1 log2N Yes
Table 6. 1 Comparison of communication cost
The comparison of communication cost is shown in Table 6.1. As shown in this table, we list the number of messages which are sent by key server. As the table, our proposed scheme is the best result. For each join operation, key servers send at least messages in LKH and OFT schemes but we reduce to only need one message for multicast. For each leave operation, our proposed scheme is also the best result. Table 6.1 shows that LKH and OFT do
2N log 2
not provide the schemes for tree balance.
6.2 Computation Cost of Group key distribution
The comparison of computation cost is shown in Table 6.2 and Table 6.2. The computation operations contain AES-GCM encryption ( ), verification message integrity
KV OF
values are included key server and stations computing the integrity check for each round-trip message, encrypting the delivered keys, verifying other members obtain the correct keys, and computing the auxiliary keys in OFT and our scheme. The delivered key is able to be appended in a key distribution message. The delivered auxiliary keys to the same station thus needs only one message. The computation time is improved since the number of group member raises. Key server is
TGCM
(TICV), key verification ( ), and one-way function for auxiliary key computation ( ). The
the bottleneck of the central group key management architecture.
icroseconds, and a 128-bit SHA-256 takes about 0.577 m
171 microseconds, and a 128-bit SHA-256 takes about 3.65 microseconds.
T T
A famous speed benchmarks for some of the most commonly used cryptographic algorithms are specified in [15], which run on an Intel Core 2 1.83 GHz processor under Windows in 32-bit mode. A 128-bit AES-GCM operation takes about 0.15 microseconds, a 1000-byte AES-GCM operation takes about 12.35 m
icroseconds on common stations.
Intel IXP 465 network processor [20] integrates hardware acceleration of popular cryptography algorithms for protected applications. The performance of this network process can support encryption and decryption rates of up to 70Mbps for AES algorithm.
Consequently, a 128-bit AES-GCM operation takes about 1.83 microseconds, a 1000-byte AES-GCM operation takes about
Computation Cost Join
Key server New Member Old member
LKH
TGCM 3+log2N 2 log N+1 2
TICV 3N+log2N+3 N+1 2N+ log2N+2
TKV 3N N-1 2N-2
OFT
l
TGCM og2N+3 2 2
ICV 3N 3 3N/2+4
T +log2N+ N+1
TKV 2N+1 N -1 3/2N
TOF log2N - log2N
Proposed
GCM 4 2 2
T
TICV 2N+6 N+1 N+5
TKV N+2 N-1 N+1
TOF log2N-1 - log2N-1
Table 6. 2 Comparison of computation cost for join operation
Computation Cost Leave
Key server Old member
LKH
TGCM 2 log N l2 og N 2
TICV 3N+3 log2N-1 N+2log2N+1
TKV 2N-1 2N-1
TGCM log2N 1
ICV
OFT
T 2 log2N+2N N+3
TKV N N-1
TOF log2N log2N
Proposed
TGCM log2N 1
TICV 2 log N+2N N+3 2
TKV N N-1
TOF log2N-2 log2N-2
Table 6. 3 Comparison of computation cost for leave operation
The realistic computation time is plugged into the values in Table 6.2 and Table 6.3. For key server, is 1.83us, is 114us, is 1.83us, and is 3.65us. For group
members (stations), TGCM is 3.096us, TICV is 12.35us, TKV is 3.096us, and TOF is 0.577us.
The results with the number of group members as the variables are shown in Figure 6.1 to Figure 6.4.
TGCM TICV TKV TOF
The join operation of computation cost for key server and old member are shown in Figu
gure 6.4. LKH has to update much more auxiliary keys and verify that every mem
essage responded from group members cause the most computation time for key server and members. Our proposed scheme and OFT scheme only send log2N messages to update the key. Besides, our proposed scheme reduces the number of one-way function compared to OFT. In the comparison of key server leave operation with LKH and OFT schemes, our scheme improves about 33.5% and 1.5%. Moreover, the computation-costs are improved about 8.7% and 4.5% compared to our scheme and LKH or OFT for old member leave operation.
Compare to LKH and OFT, our proposed scheme has the least computation overhead in these schemes.
re 6.1 and Figure 6.2. Our proposed scheme is better than LKH and OFT due to key server that needs only deliver two multicast messages to the old members and new members.
In the worst cast, one of the old members should update log2N auxiliary keys and receive more than N-1 verification messages in LKH, and N/2 in OFT. The cost for old members, therefore, is higher than proposed scheme. In the comparison of key server join operation with LKH and OFT schemes, our scheme improves about 34.5% and 33.9%. Moreover, the computation-costs are improved about 66% and 32.7% compared to our scheme and LKH or OFT for old member join operation.
The leave operation of computation cost for key server and old member are shown in Figure 6.3 and Fi
ber obtains the new keys. Thus, the overhead is on the computing the integrity of the messages. The m
Figure 6. 1 Comparison of computation time with join operation for key server
Figure 6. 2 Comparison of computation time with join operation for old member
Figure 6. 3 Comparison of computation time with leave operation for key server
Figure 6. 4 Comparison of computation time with leave operation for old member
6.3 Transmission Time of Data Forwarding
In this section, we compare original MACsec and Linksec with our proposed architecture.
The data frames must be decrypted and re-encrypted when they pass through all the internal switches in MACsec and Linksec.
The performance of the proposed station-to-station communication architecture is evaluated by comparing it with MACsec or Linksed. NS2 (Network Simulator) [20] is an excellent and widely used research tool. The evaluation is based on NS2 for background affic generation to create a local area network environment. Accordingly, the hardware computation time for an AES operation on Cisco Catalyst 4948 supporting Gigabit Ethernet is about 5.5 microseconds [19]. The switch is with a 266MHz CPU. Thus, we insert the encryption processing time into the simulation using NS2.
In the simulation, the environment is the station nodes connected to a switch node with 1Gb bandwidth and 0us delay. The analysis is transmission time of a TCP data flow from one station passing through the switch node to the other station. We calculate the average transmission time is shown in Figure 6.5. The curved lines are no encryption, proposed and MACsec. The result shows that the AES operation is the overhead for data communication.
Comparison of MACsec and no encryption, AES operation causes about 50% delay time during the traffic is high. In addition, our proposed scheme has about 12% improvement compare to MACsec. Consequently, the results show that reduces AES operation times is able to alleviate the latency of data flows.
tr
Figure 6. 5 Transmission Time of One Data Flow with AES Encryption
Chapter 7
Conclusion
d for MAC layer security. In order to
com
station-to-station key protocol. The station key handshake protocol reduces the overhead of
sche proposed
mes ckward secrecy and
prop
other works. Our proposed scheme enhances computation time for key server and group
muc d.
In this paper, we first introduce a new standar
enhance and complement the insufficiency of MACsec, we propose a new secure group munication scheme, and provide the procedure of group key distribution protocol and
encryption computation on internal devices during the data delivery. There is no key tree me addresses tree balance. In our scheme, the tree balance procedure is thus
that key server and group members record and distribute the lowest number of keys and sages. In summary, the proposed protocols provide forward and ba
against replay attack, active attack, and passive attack. We further prove the correctness of the osed protocols by SVO logic. At last, we compare our group communication scheme to
members during joining and leaving operations. In addition, the computation cost is lessened h more since the number of group members is raise
Reference
[1] I
AC) Security. Available at http://www.ieee802.org/1/f
[2] I 2.1X-2004 Draft 2.9 - Port Based Network Access
http://www.intel.com.ru/netcomms/casestudies/linksec.pdf, 2006.
ent Protocol (GKMP) Architecture,”
[5] C unications
s," IETF, RFC 2627, 1999.
way are Engineering, May 2003.
an Saha, re Internet Multicast using Boolean Function Minimization Techniques,” IEEE INFOCOM 1999, p. 689-698.
[9] Xiaozhou Steve Li, Yang Richard Yang, Mohamed G. Gouda, and Simon S. Lam, “Batch Rekeying for Secure Group Communications,” ACM SIGCOMM 2001, p. 525-534.
[10] X. Brian Zhang, Simon S. Lam, Dong-Young Lee, and Y. Richard Yang, “Protocol Design for Scalable and Reliable Group Rekeying,” IEEE/ACM Transcations on
EEE P802.1AE/D5.1 Draft Standard for Local and Metropolitan Area Networks: Media Access Control (M
ile/private/ae-drafts/d5/802-1ad-d5-1.pdf , 2006.
EEE 802.1X-REV - Revision of 80
Control. Available at http://www.ieee802.org/1/files/private/x-REV-drafts/d2/8 02-1X-r ev-d2-9.pdf, 2008.
[3] Prashant Dewan, Larry Swanson, Mem Long, “Are Your Company Secrets Really Safe?”
Available at
[4] H. Harney, C. Muckenhirn, “Group Key Managem
Internet Engineering Task Force, Request for Comment 2094, 1997.
hung Kei Wong, Mohamed Gouda, and Simon S. Lam, “Secure Group Comm
Using Key Graphs,” IEEE/ACM Transcations on Networking, Vol. 8, No. 1, February 2000, p. 16-30.
[6] E. Harder, D. M. Wallner, R. C. Agee, "Key Management for Secure Internet Multicast:
Issues and Architecture
[7] D. McGrew, A. Sherman, “Key Establishment in Large Dynamic Groups Using One-Function Trees,” IEEE Transactions on Softw
[8] Isabella Chang, Robert Engel, Dilip Kandlur, Dimitrios Pendarakis, and Debanj
“Key Management for Secu
Networking, Vol. 11, No. 6, December 2003, p. 908-922.
[11] S. Banerjee, B. Bhattacharjee, “Scalable Secure Group Communication over IP Multicast,” IEEE Journal on Selected Areas in Communications, vol. 20, No. 8, October 2002.
[12] B. Aoba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, 2004.
[12] B. Aoba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, 2004.