The SQN verification mechanism does

The SQN verification mechanism does have to satisfy certain requirements.
•The fundamental requirement is that no SQN shall be used twice. Once the USIM has
successfully verified an AUTN, it shall not accept another AUTN with the same SQN.
•It is additionally required according to [TS33.102] that the SQN verification mechanism
shall, to some extent, allow the out-of-order use of sequence numbers. Out-of-order use
of SQNs may occur, for example, when two different entities such as a MSC/VLR and
an SGSN each request a batch of AVs from the HSS (e.g. with SQNs 1 – 5 in the first
batch and 6 – 10 in the second batch) and then use the AVs from the batches in AKA
runs with the UE in an interleaved fashion. If the USIM simply kept track of the highest
SQN received in a successfully verified AUTN and rejected all lower SQNs received
later, then this would lead to so-called synchronization failures (a particular form of
authentication failures explained below in this chapter) when SQNs were presented
to the USIM out of order. Therefore, the additional requirement mentioned here was
120 LTE Security
introduced to ensure that the authentication failure rate due to synchronization failures
remained sufficiently low. For this purpose, the USIM must be able to store informa-tion relating to sequence numbers received in past successful authentication events.
3GPP even specified a threshold value for the out-of-order use of sequence numbers:
if the received SQN is among the last 32 sequence numbers generated, then it shall
be accepted if it was not used in a previous successful authentication. This could be
achieved, for example, by using a suitable window mechanism, but more sophisticated
methods are available – see Annex C.2 of [TS33.102].
•However, a USIM may reject a time-based sequence number if it was generated too
long ago. This check, if applied, takes precedence over the requirement in the previous
paragraph.
•The SQN verification mechanism may additionally check that an SQN is not accepted
if the jump from the last successfully received SQN is too big.
These various conditions on the SQN verification mechanism explain the formulation
that the USIM checks whether the SQN is ‘in the correct range’.
Authentication Responses
If the sequence number is considered to be in the correct range, the USIM computes
RES=f2K (RAND) and sends it to the ME, which includes RES in an Authenti-cation Response message to the MME. The USIM also computes the cipher key
CK=f3K(RAND) and the integrity key IK=f4K(RAND). The USIM sends CK and
IK to the ME. A USIM may also support a key conversion function that converts the
pair (CK, IK) into a GSM cipher key Kc. If the USIM does support this function, it also
sends the so-derived Kc to the ME. If the ME supports 128-bit GSM encryption, the ME
also computes the GSM key Kc
128 from CK and IK. For the use of these keys Kc and
Kc128
, see Section 4.4.
Upon receipt of the Authentication Response message, the MME checks whether the
received RES matches the XRES from the selected AV. If it does, then the authentication
of the user has been successful.
Up to this point, there are no functional differences between UMTS AKA and EPS AKA
in the handling of authentication requests, verification in the USIM and authentication
responses.
EPS AKA additionally requires, however, that an ME accessing E-UTRAN shall check
during authentication that the AMF separation bit is set to ‘1’. The ME ensures by
performing this check that the AV used in the current authentication run was marked
by the AuC as ‘for EPS use’ indeed. This check is in turn a prerequisite for successful
implicit SN authentication. When the ME receives (CK, IK) from the USIM, the ME
computes K
ASMEusing the same KDF and the same input parameters as the HSS. After
this, CK and IK can be deleted in the ME.
Key Storage on the USIM
In contrast to UMTS AKA, the ME does not request the USIM to store CK and IK
resulting from an EPS AKA run. The reason for this is that EPS AKA shall work with
EPS Authentication and Key Agreement 121
USIMs from earlier 3GPP releases, and such a USIM may have already stored a pair
(CK, IK) from a previous UMTS AKA run. If this pair was overwritten with the pair
(CK, IK) generated during the recent EPS AKA run, this would lead to problems when
EPS security context and UMTS security context had to be held simultaneously (for the
purposes of interworking between E-UTRAN and 3G – see Chapter 11). It is only for
EPS-enhanced USIMs that the ME requests the USIM to store an appropriate subset of
the EPS security context upon certain events (see Section 7.4).
Authentication Failures
A detailed description of the behaviour of UE and MME upon an authentication
failure, together with the cause values, is given in clause 5 of [TS24.301]. We give an
overview here.
•MAC code failure. If the USIM determines that MAC differs from XMAC, it indicates
this to the ME, which sends an Authentication Failure message back to the MME with
an indication of the cause.
•Synchronization failure. This occurs when the USIM determines the sequence number
to not be in the correct range. The behaviour of the USIM and the AuC in this case is
the same for UMTS AKA and EPS AKA and is described in clause 6.3 of [TS33.102].
The USIM computes a parameter AUTS as shown in Figure 7.4, which is taken from
Figure 10 in [TS33.102]. AUTS is included in an Authentication Failure message from
the UE to the MME. The MME forwards AUTS to the HSS requesting new AVs.
The AMF used to calculate MAC-S is set to all zeros so that it does not need to be
transmitted back to the HSS. The HSS uses AUTS to synchronize SQN
HEstored in
the HSS with SQN
MScontained in AUTS. The details of how the HSS handles AUTS
can be found in clause 6.3.5 of [TS33.102]. The only caveat is that the HSS needs to

Kết quả (Việt) 1:

The SQN verification mechanism does have to satisfy certain requirements.•The fundamental requirement is that no SQN shall be used twice. Once the USIM hassuccessfully verified an AUTN, it shall not accept another AUTN with the same SQN.•It is additionally required according to [TS33.102] that the SQN verification mechanismshall, to some extent, allow the out-of-order use of sequence numbers. Out-of-order useof SQNs may occur, for example, when two different entities such as a MSC/VLR andan SGSN each request a batch of AVs from the HSS (e.g. with SQNs 1 – 5 in the firstbatch and 6 – 10 in the second batch) and then use the AVs from the batches in AKAruns with the UE in an interleaved fashion. If the USIM simply kept track of the highestSQN received in a successfully verified AUTN and rejected all lower SQNs receivedlater, then this would lead to so-called synchronization failures (a particular form ofauthentication failures explained below in this chapter) when SQNs were presentedto the USIM out of order. Therefore, the additional requirement mentioned here was120 LTE Securityintroduced to ensure that the authentication failure rate due to synchronization failuresremained sufficiently low. For this purpose, the USIM must be able to store informa-tion relating to sequence numbers received in past successful authentication events.3GPP even specified a threshold value for the out-of-order use of sequence numbers:Nếu đội nhận được là một trong số cuối 32 thứ tự tạo ra, sau đó nó sẽđược chấp nhận nếu nó đã không được sử dụng trong một xác thực thành công trước đó. Điều này có thểđạt được, ví dụ, bằng cách sử dụng một cơ chế thích hợp cửa sổ, nhưng phức tạp hơnphương pháp có sẵn-xem phụ lục C.2 của [TS33.102].•However, một USIM có thể từ chối một số thời gian dựa trên trình tự nếu nó đã được tạo ra quálâu rồi. Kiểm tra này, nếu áp dụng, sẽ ưu tiên hơn các yêu cầu tại trướcđoạn văn.•Mã đội trong cơ chế xác minh có thể ngoài ra kiểm tra rằng một phi đoàn không được chấp nhậnNếu nhảy từ cuối cùng nhận thành công đội là quá lớn.Giải thích các điều kiện khác nhau trên cơ chế xác minh đội trong xây dựngrằng USIM sẽ kiểm tra xem đội là 'trong phạm vi hợp lệ'.Phản ứng xác thựcNếu số chuỗi được coi là trong phạm vi hợp lệ, USIM tínhRES = f2K (RAND) và gửi nó để ME, trong đó bao gồm RES trong thông báo phản ứng Authenti-cation MME. The USIM cũng tính chìa khóa mật mãCK=f3K(Rand) và sự tích hợp phím IK=f4K(RAND). USIM gửi CK vàIK với tôi Một USIM cũng có thể hỗ trợ một chức năng quan trọng chuyển đổi chuyển đổi cácCặp (CK, IK) vào một GSM yếu phím Kc. Nếu USIM hỗ trợ chức năng này, nó cũnggửi Kc thu vì vậy với tôi Nếu ME hỗ trợ mã hóa 128-bit GSM, the MEcũng tính chìa khóa GSM Kc128 từ CK và IK. Đối với việc sử dụng các phím Kc vàKc128, xem phần 4.4.Sau khi nhận được phản ứng xác thực thông báo, kiểm tra MME cho dù cácnhận được RES phù hợp với XRES từ AV. đã chọn Nếu nó không, sau đó việc xác thựccủa người sử dụng đã được thành công.Đến thời điểm này, không có không có chức năng biệt UMTS AKA và EPS AKAtrong xử lý các yêu cầu xác thực, xác minh trong USIM và xác thựchồi đáp.EPS AKA ngoài ra yêu cầu, Tuy nhiên, một ME truy cập E-UTRAN sẽ kiểm tratrong khi xác thực AMF tách bit thiết lập để '1'. ME đảm bảo bằngthực hiện kiểm tra này AV được sử dụng trong việc xác thực hiện tại chạy được đánh dấubởi AuC như 'để sử dụng EPS' thực sự. Kiểm tra này lần lượt là một điều kiện tiên quyết cho thành côngtiềm ẩn SN xác thực. Khi ME nhận được (CK, IK) từ USIM, the MEtính KASMEusing danh KDF tương tự và các thông số đầu vào tương tự như các HSS. Sau khinày, CK và IK có thể bị xóa trong ME.Các lưu trữ quan trọng trên USIMTrái ngược với UMTS AKA, the ME không yêu cầu USIM để lưu trữ CK và IKkết quả từ một EPS AKA chạy. Lý do cho điều này là rằng EPS AKA sẽ làm việc vớiEPS xác thực và quan trọng thỏa thuận 121USIMs từ phiên bản trước của 3GPP, và USIM như vậy có thể đã có lưu trữ một cặp(CK, IK) từ một trước UMTS AKA chạy. Nếu cặp này được ghi đè bằng các cặp(CK, IK) tạo ra trong các tại EPS AKA chạy, điều này sẽ dẫn đến các vấn đề khiBối cảnh an ninh EPS và UMTS bối cảnh an ninh đã được tổ chức cùng một lúc (cho cácmục đích của liên giữa E-UTRAN và 3 G-xem chương 11). Đó là chỉ choTăng cường EPS USIMs ME yêu cầu USIM để lưu trữ một tập hợp con thích hợp củabối cảnh an ninh EPS sau khi sự kiện nhất định (xem phần 7.4).Xác thực thất bạiMột mô tả chi tiết của các hành vi của UE và MME khi một xác thựcthất bại, cùng với các giá trị nguyên nhân gây ra, được đưa ra trong điều khoản 5 trong [TS24.301]. Chúng tôi cung cấp cho mộtTổng quan ở đây.•Mac mã thất bại. Nếu USIM xác định rằng MAC khác với XMAC, nó chỉ raĐiều này để ME, gửi một thông báo lỗi xác thực về MME vớimột dấu hiệu của nguyên nhân.•Synchronization thất bại. Điều này xảy ra khi USIM xác định số lượng trình tựkhông được trong phạm vi hợp lệ. Hành vi của USIM và AuC trong trường hợp này làtương tự cho UMTS AKA và EPS AKA và được mô tả trong điều khoản 6.3 trong [TS33.102].USIM tính một tham số AUTS như minh hoạ trong hình 7.4, mà được lấy từHình 10 tại [TS33.102]. AUTS được bao gồm trong một thông báo lỗi xác thực từUE để MME. The MME chuyển tiếp AUTS đến HSS các yêu cầu mới AVs.AMF sử dụng để tính toán MAC-S được thiết lập để tất cả Zero do đó nó không cần phảichuyển trở lại đến các HSS. HSS là sử dụng AUTS để đồng bộ hóa độiHEstored trongHSS với độiMScontained trong AUTS. Các chi tiết về cách HSS xử lý AUTScó thể được tìm thấy tại khoản 6.3.5 của [TS33.102]. The caveat chỉ là rằng HSS cần phải

Kết quả (Việt) 2:

Các cơ chế xác minh SQN không có để đáp ứng yêu cầu nhất định.
• Các yêu cầu cơ bản là không có SQN sẽ được sử dụng hai lần. Khi USIM đã
xác minh thành công một AUTN, nó sẽ không chấp nhận một AUTN với SQN cùng.
• Đó là yêu cầu bổ sung theo [TS33.102] rằng cơ chế xác minh SQN
thì đến một mức độ nào, cho phép các out-of-order sử dụng số thứ tự. Out-of-order sử dụng
của SQNs có thể xảy ra, ví dụ, khi hai thực thể khác nhau như một MSC / VLR và
một SGSN từng yêu cầu một loạt các AV từ HSS (ví dụ như với SQNs 1-5 trong lần đầu tiên
hàng loạt và 6 - 10 trong đợt thứ hai) và sau đó sử dụng AV từ lô trong AKA
chạy với UE trong một thời trang xen kẽ. Nếu USIM chỉ đơn giản là lưu giữ theo dõi cao nhất
SQN nhận được trong một AUTN xác nhận thành công và từ chối tất cả SQNs thấp hơn nhận được
sau đó, sau đó điều này sẽ dẫn đến cái gọi là thất bại đồng bộ hóa (một dạng đặc biệt của
thất bại chứng thực giải thích dưới đây trong chương này) khi SQNs là được trình bày
với USIM trong trật tự. Do đó, yêu cầu bổ sung đề cập ở đây là
120 LTE an
giới thiệu để đảm bảo rằng tỷ lệ thất bại xác thực do các lỗi đồng bộ hóa
vẫn đủ thấp. Với mục đích này, các USIM phải có khả năng lưu trữ thông tin trong báo-tion liên quan đến số thứ tự nhận được trong các sự kiện xác thực thành công trong quá khứ.
3GPP thậm chí còn quy định một giá trị ngưỡng cho out-of-order sử dụng số thứ tự:
nếu SQN nhận là một trong những cuối cùng 32 số thứ tự tạo ra, sau đó nó sẽ
được chấp nhận nếu nó không được sử dụng trong xác thực thành công trước đó. Điều này có thể
đạt được, ví dụ, bằng cách sử dụng một cơ chế cửa sổ phù hợp, nhưng phức tạp hơn
phương pháp có sẵn - xem Phụ lục C.2 của [TS33.102].
• Tuy nhiên, một USIM có thể từ chối một số thứ tự theo thời gian nếu nó đã được tạo ra quá
lâu. Việc kiểm tra này, nếu được áp dụng, được ưu tiên hơn các yêu cầu trong trước
đoạn văn.
• Cơ chế xác minh SQN có thể kiểm tra thêm rằng một SQN không được chấp nhận
nếu nhảy từ cuối cùng thành công nhận được SQN là quá lớn.
Những điều kiện khác nhau về việc xác minh SQN cơ chế giải thích việc xây dựng
các USIM kiểm tra xem các SQN là "trong phạm vi chính xác.
Responses xác thực
Nếu số thứ tự được coi là trong phạm vi chính xác, USIM tính
RES = f2K (RAND) và gửi nó đến các ME, trong đó bao gồm RES trong một thông báo đáp ứng Authenti-cation đến MME. Các USIM cũng tính mật mã chủ chốt
CK = f3K (RAND) và phím toàn vẹn IK = f4K (RAND). Các USIM gửi CK và
IK với ME. Một USIM cũng có thể hỗ trợ một chức năng chuyển đổi quan trọng có thể chuyển đổi các
cặp (CK, IK) vào một khóa mật mã Kc GSM. Nếu USIM không hỗ trợ chức năng này, nó cũng
gửi Kc để có nguồn gốc từ các ME. Nếu ME hỗ trợ mã hóa GSM 128-bit, ME
cũng tính chìa khóa GSM Kc
128 từ CK và IK. Đối với việc sử dụng các phím Kc và
Kc128
, xem phần 4.4.
Khi nhận được thông báo xác thực đáp ứng, kiểm tra MME liệu
nhận được RES phù hợp với XRES từ AV chọn. Nếu có, sau đó xác thực
của người sử dụng đã thành công.
Tính đến thời điểm này, không có sự khác biệt về chức năng giữa UMTS AKA và EPS AKA
trong việc xử lý các yêu cầu xác thực, xác minh trong USIM và xác thực
câu trả lời.
EPS AKA yêu cầu bổ sung, Tuy nhiên, đó là một ME truy cập E-UTRAN phải kiểm tra
khi xác thực rằng các bit tách AMF được thiết lập để "1". ME đảm bảo bởi
thực hiện kiểm tra này mà AV được sử dụng trong xác thực chạy hiện tại được đánh dấu
bởi AuC là 'cho EPS sử dụng' thực sự. Việc kiểm tra này là lần lượt một điều kiện tiên quyết cho thành công
xác thực SN ngầm. Khi nhận ME (CK, IK) từ USIM, ME
tính K
ASMEusing các KDF cùng và các thông số đầu vào tương tự như HSS. Sau
này, CK và IK có thể bị xóa trong ME.
lưu trữ chính trên USIM
Ngược lại với UMTS AKA, ME không có yêu cầu USIM để lưu trữ CK và IK
kết quả từ một cuộc chạy EPS AKA. Lý do cho điều này là EPS AKA sẽ làm việc với
EPS xác thực và Hiệp định chính 121
USIMs từ trước 3GPP phát hành, và như vậy một USIM có thể đã được lưu trữ một cặp
(CK, IK) từ một UMTS trước AKA chạy. Nếu cặp đôi này đã được ghi đè bằng các cặp
(CK, IK) tạo ra trong EPS gần đây AKA chạy, điều này sẽ dẫn đến các vấn đề khi
bối cảnh EPS an ninh và UMTS bối cảnh an ninh đã được tổ chức đồng thời (đối với
mục đích của liên kết mạng giữa E-UTRAN và 3G - xem Chương 11). Nó chỉ dành cho
EPS tăng cường USIMs rằng ME yêu cầu USIM để lưu trữ một tập hợp con thích hợp của
bối cảnh EPS an ninh khi sự kiện nào đó (xem Phần 7.4).
Thất bại xác thực
Mô tả chi tiết về hành vi của UE và MME khi một xác thực
thất bại, cùng với các giá trị nguyên nhân, được đưa ra trong khoản 5 [TS24.301]. Chúng tôi cung cấp một
cái nhìn tổng quan ở đây.
• Suy mã MAC. Nếu USIM xác định rằng MAC khác XMAC, nó chỉ
này để các ME, mà sẽ gửi một thông báo xác thực thất bại trở về MME với
một dấu hiệu của sự nghiệp.
• Đồng bộ hóa thất bại. Điều này xảy ra khi USIM xác định số thứ tự
để không ở trong phạm vi chính xác. Các hành vi của USIM và AuC trong trường hợp này là
như nhau cho UMTS AKA và EPS AKA và được mô tả trong mục 6.3 của [TS33.102].
Các USIM tính một AUTS tham số như trong hình 7.4, được lấy từ
hình 10 [TS33.102]. AUTS được bao gồm trong một thông báo xác thực thất bại từ
các UE đến MME. MME chuyển AUTS đến HSS yêu cầu AV mới.
Các AMF được sử dụng để tính toán MAC-S được thiết lập để tất cả các số để nó không cần phải được
truyền lại cho các HSS. HSS sử dụng để đồng bộ hóa AUTS SQN
HEstored trong
HSS với SQN
MScontained trong AUTS. Các chi tiết về cách thức xử lý HSS AUTS
có thể được tìm thấy tại khoản 6.3.5 của [TS33.102]. Thông báo trước là HSS cần