Network authentication method, device, and system
11223954 · 2022-01-11
Assignee
Inventors
Cpc classification
H04L63/00
ELECTRICITY
H04L9/3252
ELECTRICITY
International classification
H04W12/122
ELECTRICITY
H04L9/32
ELECTRICITY
Abstract
A network authentication system comprises user equipment (UE), a service network (SN) and a home network (HN). The HN generates an expected user response (XRES) based on an identifier of the UE and generate an indicator, and sends the part of XRES and the indicator to the SN. The SN receives the part of XRES and indicator, and receives a user response (RES) from the UE. The SN then compares the RES with the XRES base on the indicator, and sends a confirmation message to the HN when the comparison succeeds.
Claims
1. A network authentication system, comprising: a service network comprising at least one hardware processor; and a home network comprising at least one hardware processor; wherein the home network is configured to: send a check value X to the service network, the check value X is derived from an expected user response (XRES) and a key (K) by a hash-type function, the check value X is a message authentication code (MAC) value, and the hash-type function is a MAC function; and send an indication identifying the MAC function to the service network; and wherein the service network is configured to: receive the check value X; receive a user response from user equipment; apply the hash-type function to the user response to generate a hashed result; and compare the hashed result with the check value X to determine whether the hashed result matches the check value X.
2. The network authentication system according to claim 1, wherein the service network is further configured to send the user response to the home network, and wherein the home network is further configured to check the user response.
3. The network authentication system according to claim 1, wherein the XRES is generated based on an international mobile subscriber identity (IMSI) of the user equipment.
4. A method for authentication, comprising: receiving, by a service network, a check value X from a home network, wherein the check value X is derived from an expected user response (XRES) and a key (K) by a hash-type function, the check value X is a message authentication code (MAC) value, and the hash-type function is a MAC function; receiving, by the service network from the home network, an indication identifying the MAC function; receiving, by the service network, a user response from user equipment; applying, by the service network, the hash-type function to the user response to generate a hashed result; and comparing the hashed result with the check value X to determine whether the hashed result matches the check value X.
5. The method according to claim 4, further comprising: sending, by the service network, the user response to the home network such that the user response is checked by the home network.
6. The method according to claim 4, wherein the XRES is generated based on an international mobile subscriber identity (IMSI) of the user equipment.
7. An apparatus for network authentication, comprising: a processor; and a memory storing executable instructions; wherein the processor is configured to execute the executable instructions to: receive a check value X from a home network, wherein the check value X is derived from an expected user response (XRES) and a key (K) by a hash-type function, the check value X is a message authentication code (MAC) value, and the hash-type function is a MAC function; receive from the home network an indication identifying the MAC function; receive a user response from user equipment; apply the hash-type function to the user response to generate a hashed result; and compare the hashed result with the check value X to determine whether the hashed result matches the check value X.
8. The apparatus according to claim 7, wherein the processor is further configured to send the user response to the home network.
9. The apparatus according to claim 7, wherein the XRES is generated based on an international mobile subscriber identity (IMSI) of a user equipment.
Description
BRIEF DESCRIPTION OF DRAWINGS
(1) To describe the technical solutions in the embodiments of the present invention more clearly, the following briefly introduces the accompanying drawings required for describing the embodiments. Apparently, the accompanying drawings in the following description show merely some embodiments of the present invention, and a person of ordinary skill in the art may still derive other drawings from these accompanying drawings without creative efforts.
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
DESCRIPTION OF EMBODIMENTS
(11) The following clearly and completely describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are merely some but not all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.
(12) We will describe methods for mitigating the attack.
(13) Method 1
(14) The attacker's UE (user equipment) changes the part of RES which SN (service network) cannot check against XRES (expected user response). To do that, the attacker's UE has to know what part of XRES the SN has received from HN (home network). Thus, in order to mitigate the attack, the UE should be unaware which part of XRES is known to the SN. It is clear that a static setting of this part can be eventually discovered by an attacker; the setting should be dynamic and hard to predict. This implies that HN shall choose at random the part of XRES that it sends to SN.
(15) We give an example of how this can be implemented. Before sending the AV* to the SN, the HN generates a random number r that is either zero or one. If r=0, then the HN includes the lower part of XRES in the AV*; otherwise, the HN includes the upper part of XRES in the AV*. The HN must also somehow indicate to the SN which part of the XRES shall be used to check the RES. For instance, the HN could include in the AV* the value of r; or, instead of the value of r, it could include a mask of 2n bits (the size of XRES), where the bits corresponding to the part of the XRES that the SN needs check against RES are set to one, and all other bits are set to zero. In any event, the HN should include in Authentication Information Reply message a field which indicates to the SN which part of XRES the SN should check against RES, and/or which part it should not.
(16) With this countermeasure in place the attacker's ME can only guess which part of RES it needs to modify. Observe that a wrong guess of the attacker may be noticed by the subscriber, because his UE will not receive service from the SN. (Still, if the attacker's ME guesses wrongly, it can immediately initiate another EPS AKA* procedure run—and reply with the correct RES this time.) Observe also, that is enough for the attacker to modify just one bit in the part of RES that is not known to the visited SN, in order to make that SN suspect of billing fraud.
(17) How to include mask in selection corresponding part of XRES:
(18) Using XRES and mask as input parameters of a selection function, and the output of the selection function could be the selected bits of XRES.
(19) Based on the communication progress of
(20) One possible example of mask:
(21) Using XRES and mask as input parameters of a selection function, and the output of the selection function could be the selected bits of XRES. In the mask the bits corresponding to the part of the XRES that the SN needs check against RES are set to one, and all other bits are set to zero, and output would be the selected bits of XRES, where the bit with value of 1 in the mask would be the bit selected in XRES. The other option is that the bit with value of 0 in the mask would be the bit selected in XRES.
(22) Based on the communication progress of
(23) Let us denote by m the number of bits in the part of RES that is not checked by the SN against the corresponding part of XRES. If the attacker's ME flips one, randomly chosen bit of RES before sending the modified RES to the SN, then the probability p that the the bit chosen by the attacker will be one of those m bits is m/(2n). For example, EPS AKA*, as described in TR 33.899 [1] sets m=n; with that setting the probability p is one half.
(24) Since making m smaller reduces p, the best setting (for reducing p) is m=1. With that setting the probability p (the attacker's probability to pass the SN check) reduces to 1/(2n): for example, when the size of RES, 2n=32, the probability p is 1/32, or about 3 percent; when 2n=64, the probability p is about 1.5 percent; and when 2n=128, the probability p is about 0.8 percent.
(25) With the setting of m=1, the indicator field in Authentication Information Reply message from HN to SN could be an integer which points to the position of the (single) bit in XRES that the SN should not check against RES.
(26) Remember, however, that the attacker may be SN, rather than the UE. In the above mitigation method (Method 1), the probability that the attacker SN succeeds in guessing that part of XRES that it does not know is 1−p: as we decrease the chances of attacker UE (by decreasing p), we increase the chances of attacker SN, and vice versa. In addition, p of one to three percent is rather large. We will next describe a more effective way to protect against both attacker UE and against attacker SN. It achieves that both p and 1−p equal to ½.sup.n. For example, if the size of RES 2n=32, then p=½.sup.16, that is in the order of one thousandth of a percentage point.
(27) Method 2
(28) In this scheme the HN does not send any parts of XRES explicitly to SN but instead HN sends an n-bit check value X for checking the UE's response RES. The check value X is derived from the 2n-bit XRES by a suitable hash-type function ƒ The HN also indicates to the SN what the function is.
(29) For example, the value X could be a message authentication code (MAC) value computed for XRES by a one-time key that is sent by HN to SN together with X.
(30) Another possibility is to encrypt XRES with a block cipher whose block length is 2n. The check value X would now be the lower part of the encrypted XRES. Again, the one-time key used for encryption is sent together with X.
(31) When SN receives RES from the UE, it first applies the hash-type function ƒ to the received RES and checks whether the result matches X. For the additional check by the HN, the SN sends whole RES to HN in Authentication Confirmation message.
(32) As shown in
(33) Solutions to Calculate X:
(34) Solution 1
(35) Using K and XRES as inputs of a MAC function, and the output of the MAC function is X. the K could be a one time key. Another possibility is the K is a shared key between HN and SN. Another option is K is derived from shared key(s) between HN and SN. Still another option is K is negotiated between HN and SN based on public key or certificates.
(36) As shown in
(37) Solution 2
(38) Using K and XRES as inputs of an encryption function, and the output of the encryption function is X. the K could be a one time key. Another possibility is the K is a shared key between HN and SN. Another option is K is derived from shared key(s) between HN and SN. Another option is K is negotiated between HN and SN based on public key or certification.
(39) As shown in
(40) Let us now calculate the chances of cheating for both UE and SN when Method 2 is used. The UE does not know the key with which the SN is going to apply the hash-type function. Therefore, UE has no way of knowing which other values of RES would lead to the same value of X. (Actually, UE does not even know the value X either but that is not relevant here.) Therefore, the best strategy for UE is to simply guess, and success probability is 1 out of 2.sup.n.
(41) The SN knows the key and it knows the value X but without executing the authentication with the (valid) UE it does not know RES: With the key and the value X, it is possible (although cumbersome) for SN to compute (many) values of RES that would lead to X. But the cheating SN has no way to find out which of the many RES-values would be the correct one. Again, the success chance is (at least in average) 1 out of 2.sup.n.
(42) Both of the probability values follow from the fact that (at least in average) each value X is obtained from n different RES-values when the hash-type function is applied with a fixed key.
(43) Note that by changing the length of X, different trade-offs would be achieved between chances of cheating in the two cases: first case is a cheating UE, another one is a cheating SN.
(44) Note also that the function to compute X does not need to be based on either encryption or hash-type function. To protect against cheating UE, it is sufficient that the choice of different functions is large enough to guarantee that the UE cannot find an alternative parameter RES' that could be sent instead of RES and still get accepted by SN with big enough probability. To protect against cheating SNs, it is sufficient that there are sufficiently many parameters RES' that could be received instead of RES and still get accepted by SN.
(45) Method 3
(46) In this scheme the HN does not send any parts of XRES explicitly to SN but instead HN sends an k-bit check value X for checking the UE's response RES. The check value X is derived from the 2n-bit XRES by a suitable digital signature function ƒ. The HN also indicates to the SN what the function is.
(47) For example, the value X could be a digital signature value computed for XRES by a private key (SK) that is managed by HN. And, HN sents public key (PK) and X to SN, where SK and PK are a pair of asymmetric cryptography keys.
(48) When SN receives RES from the UE, it first applies the digital signature verification algorithm to the PK, X and received RES, and checks whether the X is correct. If the verification is correct, SN considers the authentication successful. If not the SEAF rejects the authentication. For the additional check by the HN, the SN sends whole RES to HN in Authentication Confirmation message.
(49) Let us now calculate the chances of cheating for both UE and SN when Method 3 is used. The UE does not know the private key SK with which the HN is going to apply the signature function. Therefore, UE has no way of knowing which other values of RES would lead to the same value of X. (Actually, UE does not even know the value X either but that is not relevant here.) Therefore, the best strategy for UE is to simply guess the signature X, and success probability is related with digital signature security, which is much lower than 1 out of 2.sup.n.
(50) The SN only knows the public key PK and it knows the value X but without executing the authentication with the (valid) UE it does not know RES: With the key PK and the value X, it is not possible (although cumbersome) for SN to compute a correct X for any RES. Therefore, the cheating SN has no way to find out which of the many RES-values would be the correct one. The success chance is (at least in average) 1 out of 2.sup.n.
(51) Both of the probability values follow from the fact that (at least in average) each value X is obtained from n different RES-values when the digital signature function is applied with a fixed key.
(52) The other option is that X is computed based on part of XRES (e.g., the upper part). Therefore, SN verifies the X based on this part of RES (e.g., the upper part) and PK. HN and SN may negotiate that which part will be used for verification. Or, HN may dynamically select the verification part, and notify the SN the verification part via a parameter (e.g., mask as described in method 1, or one bit r for upper and lower part clarification, etc).
(53) The HN may generate the PK and SK by itself. On the other hand, the PK and SK may be preconfigured within the HN, or distributed to HN.
(54) The above asymmetric cryptography keys PK and SK could be generated dynamically for every authentication procedure, or the fixed keys for the SN and HN pair.
(55) The above asymmetric cryptography (i.e. digital signature function ƒ) denotes the general signature algorithms, including but not limited to the Digital Signature Algorithm, Schnnor signature algorithm, identity-based signature algorithm, elliptic curve digital signature algorithm, etc.
(56) As shown in
(57) As shown in
(58) As shown in
(59) It should be noted that, for brief description, the foregoing method embodiments are represented as a series of actions. However, a person skilled in the art should appreciate that the present invention is not limited to the described order of the actions, because according to the present invention, some steps may be performed in other orders or simultaneously. In addition, a person skilled in the art should also understand that all the embodiments described in this specification belong to exemplary embodiments, and the involved actions and modules are not necessarily mandatory to the present invention.
(60) Content such as information exchange and an execution process between the modules in the foregoing apparatus and system is based on a same idea as the method embodiments of the present invention. Therefore, for detailed content, refer to descriptions in the method embodiments of the present invention, and details are not described herein again.
(61) A person of ordinary skill in the art may understand that all or some of the processes of the methods in the embodiments may be implemented by a computer program instructing relevant hardware. The program may be stored in a computer-readable storage medium. When the program runs, the processes of the methods in the embodiments are performed. The storage medium may be a magnetic disk, an optical disc, a read-only memory (ROM: Read-Only Memory), a RAM, or the like.
(62) Specific examples are used in this specification to describe the principle and implementation manners of the present invention. The descriptions of the foregoing embodiments are merely intended to help understand the method and idea of the present invention. In addition, with respect to the implementation manners and the application scope, modifications may be made by a person of ordinary skill in the art according to the idea of the present invention. Therefore, this specification shall not be construed as a limitation on the present invention.