HK1143267B - Method and apparatus to implement non-access stratum (nas) security in a long term evolution wireless device - Google Patents

Description

Method and apparatus for implementing non-access stratum (NAS) security in a long term evolution wireless device

Technical Field

The present methods and apparatus relate to wireless communications. In particular, the present methods and apparatus relate to secure communications in long term evolution compatible wireless devices.

Background

The current goal of the third generation partnership project (3GPP) Long Term Evolution (LTE) is to bring new technology, new architecture and new methods to new LTE settings and configurations to provide improved spectral efficiency and reduced latency for better use of radio resources for increasingly enhanced user experience and low cost rich applications and services.

As part of this evolution process, the 3GPP group will use a different security architecture in LTE than those used in Universal Mobile Telecommunications System (UMTS) and global system for mobile communications (GSM). For comparison purposes, it is assumed that in the Packet Switched (PS) domain, the UMTS Authentication and Key Agreement (AKA) procedure is the baseline for the proposed new LTE procedure.

Figure 1 shows a UMTS access stratum protocol stack 100. UMTS AKA and ciphering procedures are overlaid on multiple protocol layers and use both non-access stratum (NAS) and Radio Resource Control (RRC) signaling for their purposes. Typically, identification and authentication of a Wireless Transmit Receive Unit (WTRU) is accomplished through NSA signaling. Once authentication at the NAS level is complete, ciphering and/or integrity protection is activated by the network using a security mode command, which is an RRC message. Once SECURITY is activated using a SECURITY mode command of the RRC layer, the WTRU passes ciphering and integrity keys (CK and IK) to an Access Stratum (AS) by using a GMMAS-SECURITY-RES primitive over a GMMAS-SAP (defined between GPRS Mobility Management (GMM) and AS). Upon receiving these keys, the RRC 110 passes the keys to a Radio Link Controller (RLC)120 and a Medium Access Control (MAC)130 by using a CRLC-CONFIG primitive (on C-SAP between RRC and RLC) and a CMAC-CONFIG primitive (on C-SAP between RRC and MAC). The C-SAP (not shown) is a service access point for C-plane signaling between RRC and lower layers. The actual ciphering and integrity protection is typically performed in the RLC 120, but in the MAC 130 in the case of transparent RLC mode communication. The lower layer (i.e., MAC/RLC) is used to ensure that messages intended for the upper layer (e.g., third layer NAS messages) have been integrity protected and/or correctly ciphered. If not, the lower layer ignores/discards the message. Once security has been activated, all C-plane and U-plane security is done in the RLC or MAC.

For LTE, a completely different architecture for security has been proposed. The main difference is that unlike the single security layer (i.e. at MAC/RLC), it employs three layers of security: NAS security, RRC security, and U-plane security. Each layer has its own key. NAS security ends up in the Mobility Management Entity (MME) and is performed in the NAS layer. RRC security ends in an evolved node B (e-NB) and is performed in Packet Data Convergence Protocol (PDCP). U-plane security consists of ciphering only (no integrity protection) and is also performed in PDCP. In short, the AKA procedure is done in NAS and NAS security keys are obtained. The RRC/U plane security parameters are obtained from the NAS key in a cryptographically separate manner. The content of the RRC/U plane key makes it impossible for an attacker to determine the NAS key. The main rationale for this decision is that in LTE the user may have an eNB in a vulnerable location, e.g. in the home. RRC and thus security ends up in the e-NB, which is therefore considered a security risk. Thereby employing two levels of security in the standard.

Fig. 2 is a structural diagram of key hierarchy in LTE 200. As shown in fig. 2, the USIM (in a wireless transmit/receive unit (WTRU)) and the authentication center (AuC)205 share a secret key K210. As part of NAS Authentication and Key Agreement (AKA) signaling (similar to the current UMTS AKA procedure), the USIM and AuC/HSS acquire Ciphering Key (CK)215 and Integrity Key (IK) 220. The method of acquiring CK 215 and IK 220 is similar to that in UMTS, where the AuC/HSS acquires the authentication vector and sends the WTRU a challenge (challenge) in a NAS message that the WTRU responds to and the HSS/AuC checks. However, unlike in UMTS where CK 215 and IK 220 are provided for the MAC/RLC layer to perform ciphering and/or integrity protection, in LTE CK 215 and IK 220 are used for the slave master key, the so-called K_ASMEThe remaining keys are derived in a key hierarchy that begins with key 225. The remaining keys are derived from K by using different Key Derivation Functions (KDF) and truncation (truncate)_ASMEDerived from the key.

K_eNB230 is WTRU and MME from K_ASME225 or K derived by the WTRU and the target eNB during eNB handover_eNB ^*The derived key. K_eNB230 for obtaining keys for RRC communication, UP communication or handover key K during eNB handover_eNB ^*。

K_NASint235 are used to integrity protect NAS signaling with a specific integrity algorithm. The key is K-derived by the WTRU and MME 237_ASME225 and is also an identifier for the integrity algorithm using the KDF.

K_NASenc240 are used to encrypt NAS signaling with a specific encryption algorithm. The key is K-derived by the WTRU and MME 237_ASME225 and is also an identifier of the encryption algorithm using the KDF.

K_UPenc245 are used to encrypt UP communications with a particular encryption algorithm. The secret key is K-derived by the WTRU and the eNB 247_eNB230 and is also an identifier of the encryption algorithm using the KDF.

K_RRCint250 are used to integrity protect RRC communications with a specific integrity algorithm. K_RRCint250 by WTRU and eNB 247 from K_eNB230, and is also an identifier of the integrity algorithm using the KDF.

K_RRCenc255 are used to encrypt RRC signaling with a specific encryption algorithm. K_RRCenc255 by WTRU and eNB from K_eNB230 and is also an identifier of the encryption algorithm using the KDF.

The RRC and U-plane keys may be derived with the C-RNTI as an input.

In existing UTRAN security architecture, the verification of correct ciphering and/or integrity protection is done in the RLC or MAC. Typically, the only security failure handling case in NAS would occur in case of authentication failure. However, in NAS, due to the separation of ciphering and integrity protection procedures, it is desirable to define NAS procedures in response to receiving NAS messages that are not correctly ciphered and/or integrity protected.

NAS relies on the AS, RLC or MAC, to verify that any received layer-3 (L3) messages have the correct security credentials, i.e., that they are correctly ciphered and integrity protected. Although the new LTE architecture with NAS layer security independent of AS security and NAS checks the security of the L3 message, this approach is not appropriate since the checking of NAS security is done AS part of the procedure defined in NAS behavior. Therefore, it is desirable to perform actions for NAS to be defined in case of failure.

Since the NAS key is independent of the RRC/U plane key (hereinafter, AS key), it is possible to initiate/reconfigure NAS ciphering independent of AS ciphering/integrity protection. It is desirable to have new messages and procedures for that process. Meanwhile, key expiration may also be related to the NAS/RRC state of the WTRU. Procedures for WTRU key handling are desired.

The RRC typically receives new CK and IK from NAS and passes them to MAC and RLC, which performs ciphering/integrity protection. However, in LTE, AS ciphering and integrity protection may be performed by PDCP. Therefore, new cross-layer procedures and primitives for proper security functions are desired.

Disclosure of Invention

A method and apparatus relating to a wireless communication system including a Wireless Transmit Receive Unit (WTRU) configured to receive unencrypted and encrypted messages. The unencrypted message may include an identity request, an authentication request, a non-access stratum (NAS) security mode instruction, and a tracking area update response. The encrypted messages may come from the NAS and a Radio Resource Controller (RRC). The message is preferably encrypted by using a security key.

Drawings

The invention will be understood in more detail from the following description, given by way of example, and understood in conjunction with the accompanying drawings, in which:

FIG. 1 is an access stratum protocol stack according to the prior art;

fig. 2 is a block diagram of key hierarchy in LTE according to the prior art;

fig. 3 is a block diagram of a specific embodiment, where a proxy server may be a mobility management equivalent layer or a new sub-layer of security in LTE NAS or some other proxy server, and the defined security parameters for a given message are incorrect;

FIG. 4 is a block diagram of a modified layer 3 protocol header including a NAS sequence number;

figure 5 is a block diagram illustrating key handling procedures in a WTRU after a transition from EMM _ connected mode to EMM _ idle mode;

fig. 6 is a block diagram of an access stratum protocol stack for LTE; and

fig. 7 is a block diagram of a wireless communication system configured for encrypted and unencrypted messages in LTE.

Detailed Description

The term "wireless transmit/receive unit (WTRU)" as referred to below includes, but is not limited to, a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a wireless telephone, a Personal Digital Assistant (PDA), a computer, or any other type of user equipment capable of operating in a wireless environment. The term "base station" as referred to below includes, but is not limited to, a node B, a site controller, an Access Point (AP), or any other type of interfacing device capable of operating in a wireless environment.

Security failure handling in NAS

In case of a security problem occurring in some other layer, for example, in case of a security problem occurring in the PDCP layer performing RRC ciphering/integrity protection, the procedure described below may be used. Procedures for security failure handling in NAS provide a set of NAS messages that may be received by a WTRU without activating ciphering and/or integrity protection in the NAS. Such a list exists only for UTRAN NAS messages, which are different from LTE NAS messages and can be received without activating RLC/MAC ciphering. A set of NAS messages that may be received by a WTRU without activating ciphering and/or integrity protection in the NAS may include, but is not limited to:

an identity request;

an authentication request;

NAS security mode instruction (at least integrity protection in NAS is activated until the instruction is received); and

tracking area update response.

In the MME, the following messages may be received without ciphering and/or integrity protection:

an identity response;

an authentication response; and

a tracking area update request.

In addition, it is confirmed that although the above messages may be received without encryption and/or integrity protection being activated, if encryption and/or integrity protection has been activated, the messages must be encrypted and/or integrity protected.

Only some other NAS messages may be sent if both NAS and RRC security have been activated. Some NAS messages may be sent if NAS security has been activated (independent of RRC security).

Fig. 3 is a block diagram 300 of an embodiment in which the proxy server is a new sub-layer of mobility management equivalent layer or security in the LTE NAS or some other proxy server. Once the NAS message is received 305, the proxy server that checks the security state of the NAS message will check if the security parameters of the message are appropriate 310. If the security parameters defined for a given message are inaccurate 315, i.e., the integrity check fails or the message is not ciphered, or if the message (according to the protocol discriminator and message type field in the header) should be received ciphered and/or integrity protected but in fact not, the NAS layer, sub-layers thereof, or the proxy server may perform any or all of the following actions in any order. The action performed may depend on the type of message for which the security parameter failed. If a security problem occurs in some other layer (e.g., RRC security failure), the procedure defined as follows can also be used:

the actions of the proxy server may be defined 320 by execution;

the proxy server may ignore and/or discard the message 325;

the proxy server may report the failure to some other protocol layer (e.g., RRC), entity 330 in the WTRU (e.g., USIM/UICC) network. If the proxy server checks the security and finds an error it can trigger, e.g. a message sent to the network informing the network of the error occurred. The report may include the reason for the failure. If some other protocol layer/entity already knows the failure, its response may be similar to that described below:

the proxy server may initiate re-authentication 335 with the network;

the proxy server may move to an Evolved Packet System (EPS) mobility management (EMM _ idle) mode or EMM _ deregistered state 340;

the proxy server may record the number of failures and take some action 345 upon repeated failures. These actions may be the same as defined herein;

the proxy server may try and rejoin the network 350; or

The proxy server may delete some or all of the stored security parameters (key/serial number/key set identifier) or may signal the entity in the WTRU that stores/manages the security parameters to do this, either directly or via an intermediary 355.

If the security parameters are correct, the NAS message may be processed 360 as defined for the particular protocol and message type. For example, the proxy server may be the mobility management equivalent layer in LTE NAS, or a new sub-layer for security or some other proxy server.

Layer 3 protocol effects

Existing layer 3 protocol headers do not contain sequence numbers. The header of the standard L3 message consists of two octets. The header consists of three main parts, protocol discriminator (1/2 octets), message type octet and half octet respectively. In some cases, this half octet is used as a transaction identifier, and in other cases, as a sub-protocol discriminator, and is referred to as a skip indicator. For example, if the protocol discriminator is set to GMM, it may be used as a skip indicator. If the protocol discriminator is set to SM, it can be used as TI or a sub-protocol discriminator. If it is used as a skip indicator, it means that the first 4 bits have no meaning for the GMM message and are "skipped".

The protocol discriminator distinguishes between Mobility Management (MM), GPRS Mobility Management (GMM), Session Management (SM) messages and similar messages. When the message type indicates the kind of message, such as attach request or PDP context activation, the transaction identifier allows the peer entity in the WTRU and in the network to distinguish up to 16 different bi-directional message flows for a given protocol discriminator and a given serving access point (SPA). This flow of messages is referred to as a transaction. An extension mechanism for Transaction Identifiers (TI) is also defined. This mechanism allows up to 256 different bi-directional message flows for a given protocol discriminator and a given SPA to be distinguished. For example, when a WTRU tries to obtain an IP address, there are SM entities in the WTRU and in the network. If the WTRU tries to obtain another IP address, another pair of SM entities is established in the WTRU and the network. The TI identifies which transaction, i.e. pairing, a particular SM message is used for.

Fig. 4 is a block diagram of a modified L3 protocol header 400 including a NAS sequence number 410. As with the existing L3 protocol header, the modified header is composed of two octets and consists of three main parts. The three main parts are the protocol discriminator 420(1/2 octets), the message type octet, and the half octet, which serves in some cases as a transaction identifier and in other cases as a sub-protocol discriminator, and is referred to as a skip indicator. For example, if the protocol discriminator is set to GMM, it may be used as a skip indicator. If the protocol discriminator is set to SM, it can be used as TI or a sub-protocol discriminator. If it is used as a skip indicator, it means that the first 4 bits have no meaning and are "skipped" for the GMM message. The modified header includes a sequence number, referred to hereinafter as a NAS SN, for the NAS message 410. Which may be included in the protocol header of the NAS message or as an Information Element (IE) in its content. The transaction identifier may also be used as a sequence number. The NAS SN may have a predetermined or negotiated period of increase. For example, it may be based on each NAS PDU (i.e., message). The NAS layer may perform duplicate detection based on sequence numbers or using any other number added using the NAS SN, where the received NAS PDU duplicate is discarded.

The NAS SN may be maintained per AS signaling radio bearer or per SAP regardless of protocol discriminator or message type. It can also be maintained every TI.

The value of COUNT may be used in the NAS layer. Increasing the COUNT value on a scheduled/negotiated basis (e.g., in each L3 message) may prevent replay (replay) or impersonation attack (impersonation attack). This is possible with NAS level encryption. A single COUNT value may be defined for all SAPs. A single COUNT-C may be defined for ciphering of all SAPs and a single COUNT-I may be defined for integrity protection of all SAPs. A combination of COUNT-C and/or COUNT-I and/or a single COUNT value may be defined for SAP. The COUNT may consist of two parameters: NAS Sequence Numbers (SNs) that are incremented according to subscription/negotiation, e.g., per NAS Protocol Data Unit (PDU) or per NAS PDU for a given SAP, and NAS super long frame numbers (NAS HFNs). The NAS HFN may be a counter that increases by one every x number as the NAS SN increases. The COUNT parameter, in whole or in part, may be initialized based on the START value during the initial access/key derivation/authentication/idle to active transition. The COUNT parameter may be used as an input to an encryption/decryption integrity protection/integrity check algorithm to ensure security.

This COUNT value needs to be set before NAS security activation. The COUNT-C parameter may be 32 bits in length or may be reduced to a smaller value since the NAS message may not require a large SN. The length of the SN field and HFN field itself may be modified in the COUNT-C parameter to optimize it for NAS level procedures. Prior art encryption engines may be used for NAS. Appropriate changes may be made to the crypto engine to accommodate smaller values of COUNT-C, or to accommodate changes in the values of the SN and HFN fields.

Alternatively, assuming that the NAS SN can be protected by RRC ciphering, the NAS COUNT value may be the NAS SN, so it is not open, so it is not absolutely necessary to conceal the HFN. NAS security may be activated no earlier than RRC security and the NAS SN may be reset immediately following NAS security activation. In addition, duplicate detection in NAS may be performed by using the NAS COUNT value.

Additional parameters instead of the length of the message or bearer ID need to be defined, which are input to the ciphering engine, or additional procedures need to be defined at the NAS to extract these parameters when the NAS layer ciphers the message.

Alternatively, instead of having 2 separate ciphering engines for RRC and NAS, a single ciphering engine operating with RRC and NAS parameters may be used on the WTRU side.

Further, ciphering of messages at the NAS level is optional, and the WTRU may indicate in its capability information whether it supports NAS level ciphering.

Key handling in a WTRU at transition from EMM _ Connected to EMM _ Idle mode

Typically, the RRC connection is released when the WTRU transitions from EMM _ Connected mode to EMM _ Idle mode. After activating idle transitions, the eNB typically does not store state information about the corresponding WTRU. The eNB typically deletes the current key from its memory.

In detail to this embodiment, the eNB may delete K after activating idle transition_eNB、K_RRCenc、K_RRCintAnd K_UPencAt least one of (a). However, the MME may store K_ASME。

Fig. 5 shows a block diagram of a key handling procedure 500 in a WTRU at the transition from EMM _ Connected mode to EMM _ Idle mode. To date, no WTRU procedure has been defined to respond to the transition. One possible procedure is that the transition indication 520 may be provided by the WTRU to an entity that stores the security key in the WTRU, such as the UICC, USIM, or mobile device, upon transitioning to EMM _ Idle mode 510. Another possible procedure is that the indication 520 may be provided by the WTRU to the storage entity when the serving e-NB changes in EMM _ Idle mode 530, such as during cell reselection to a different e-NB. The indication from the WTRU to the storage entity may include an e-NB entity so that new e-NB, RRC, and U-plane keys may be derived. For example, the NAS and/or AS may provide the indication. For this purpose, predetermined primitives including messages, IEs, interfaces and SAPs between protocol layers indicating entities and/or between indicating entities and storage entities may be defined. It should be understood that the predefined primitives include new and existing primitives that may be used. Upon receiving such a transition indication, the storage entity in the WTRU will preferably delete the appropriate key, e.g., K_eNB、K_RRCenc、K_RRCintAnd K_UPencAt least one of (3) 540. The NAS security keys and ASME keys may be selected to be retained or deleted 550.

Upon receiving an indication of an active-to-idle transition, the storage entity may delete K_RRCenc、K_RRCintAnd K_UPencAnd deleting K when receiving an indication of a change in serving e-NB, such as during a reselection to a different e-NB procedure_eNB. Optionally preserving or deleting NAS securityKeys and ASME keys. The WTRU may use K upon determining to reselect to a cell belonging to a different e-NB by reading the e-NB identity on the broadcast channel_eNBAnd "Next hop (hop) identifier" to generate a new K^* _Enb。

The storage entity may not delete any keys when transitioning from active to idle or to a new e-NB in idle mode, but delete keys when transitioning from idle to active.

The storage entity may not delete any keys when transitioning from active to idle or when transitioning to a new e-NB in idle mode. Instead, the storage entity may delete the key when a new key is generated, e.g. when the e-NB receives an RRC Connection request or a new C-RNTI is assigned.

The change in serving cell ID/C-RNTI may be indicated to the storage entity 560. The indication may be provided by the NAS and/or AS.. Alternatively, the key may be stored 570 with an associated timer value. When the WTRU goes from idle to active, or from active to idle, it can control how long the keys remain valid until finally deleted.

Effect on PDCP due to the proposed ciphering structure

Typically, ciphering for RRC and U-plane communications may be done in the PDCP layer. This results in many architectural changes in PDCP.

In this embodiment, the PDCP layer has the capability of receiving RRC keys and U-plane security keys from an upper layer. Primitives may be defined as desired. Specifically, the RRC or NAS or USIM may provide ciphering keys required for PDCP and START or COUNT or HFN or SN values required. The PDCP layer also has the capability to compute these values by itself based on RRC header information.

Referring to fig. 1, C-plane communication does not pass through PDCP. Since different radio bearers can be protected using different COUNT parameters, the PDCP layer can preferably distinguish between different communication categories. As such, the introduced SDU or the primitive carrying the SDU may have explicit information about the destination radio bearer. The PDCP layer may determine information for itself and then perform ciphering/integrity protection.

Fig. 6 is a block diagram 600 of an LTE access stratum protocol stack. Referring to fig. 6, C-plane communication passes through the PDCP layer 610. The PDCP layer 610 checks security of the incoming PDCP PDU. If the PDCP layer 610 finds that the security parameters of the incoming PDUs (i.e., mapped to either the data radio bearer or the signaling radio bearer) are incorrect (i.e., if, for example, the integrity check of the PDCP PDUs fails), the PDCP layer 610 may perform at least one of the following actions in any order. The action taken may depend on the security parameter failure type of message. If there are security issues in some other layers, for example if NAS security fails, the procedure defined below may also be used:

defining PDCP actions by enforcement;

PDCP may ignore and/or discard messages;

reporting the failure to other protocol layers, such as an RRC entity in the WTRU; notifying other protocol layers of the failure;

maintaining a count of the number of failures and taking some action such as defined herein or other action after a repeat failure (e.g., X failures in Y messages or unit time);

deleting some or all of the security parameters, such as stored keys and sequence numbers, or may directly or indirectly signal an entity in the WTRU to store or manage security parameters to do so; and

failure reports reported to other protocol layers may contain the reason for the failure.

The PDCP HFN may be used to construct a COUNT value. The COUNT value may be used in a ciphering and/or integrity protection algorithm for PDCP 510 and may be initialized by a START value. There are multiple COUNT values for each radio bearer that the PDCP can protect. The RRC 620 and the PDCP layer 610 can exchange information related to the COUNT value or its elements.

The PDCP layer 610 may verify the integrity protection of the message. This is consistent with the assumption 610 that integrity protection is in PDCP. However, the Message Authentication Code (MAC) word currently appended to the message to identify message integrity is calculated in RRC 620 appended to the RRC message and passed to RLC 630/Medium Access Control (MAC) 640. The entire message containing the MAC word is encrypted. Likewise, the PDCP layer 610 may not be able to determine whether RRC messages require protection.

At the transmitting end, the RRC layer 620 may indicate to the PDCP layer 610 whether integrity protection and/or ciphering is required or not for a given RRC message. The PDCP layer 610 can use the indication to determine whether to perform ciphering and/or integrity protection of RRC messages sent as PDCP PDUs.

The indication may be an explicit indication provided by the RRC to the PDCP layer in each RRC message that the RRC uses a new bit to send to the PDCP layer. Alternatively or additionally, the indication is implicit, e.g., ciphering and/or integrity protection in PDCP will often be turned on unless indicated, or often turned off unless indicated by RRC. For example, a 2-bit indicator may be used by RRC layer 620 to indicate that any combination of ciphering and integrity protection is active. Such an indication may be sent with each RRC message passed to the PDCP or applied to all RRC messages, and preferably as if some RRC messages were not cipherable and/or integrity protected.

Alternatively, or in addition, the RRC layer 620 may indicate to the PDCP layer 610 that all RRC messages starting with a given RRC message are to be integrity protected.

Alternatively, or in addition, the RRC layer 620 may indicate to the PDCP layer 610 that all RRC messages starting with a given RRC message are to be ciphered.

Alternatively, or in addition, the RRC layer 620 may indicate to the PDCP layer 610 that all RRC messages starting with a given RRC message are to be ciphered and integrity protected.

Alternatively, or in addition, the RRC layer 620 can provide the PDCP 610 with a generic list of RRC messages and their associated security parameters. The list may include messages received without ciphering and/or integrity protection, such as RRC connection re-establishment. The list may include messages received with encryption and/or integrity protection.

Alternatively, or in addition, a ciphering and/or integrity check flag may optionally be defined by the RRC layer 620, and if set, the PDCP layer 610 will cipher and/or integrity check all RRC messages. The PDCP layer 610 will therefore verify the signature prior to ciphering and integrity checking. There are separate flags that are set for encryption and integrity protection.

For all of the different indication mechanisms described above, the indication may be provided on a per Signaling Radio Bearer (SRB) basis, i.e., the RRC layer 620 may indicate to the PDCP layer 610 that the indication for ciphering and/or integrity protection applies to RRC messages mapped to a particular SRB by the PDCP layer 610.

For messages to be transmitted, the PDCP layer 610 may first perform integrity protection and then ciphering, or ciphering first and then integrity protection. Before either operation, the PDCP layer 610 may pad the message to an optimal length for ciphering and/or integrity protection. The PDCP layer 610 may allocate SNs before security operation. The SN may be a PDCP SN or may reuse an RRC SN, or may use other sequence numbers, such as a common sequence number. Before the security operation, the PDCP layer 610 may perform header compression for U-plane communication.

The MAC word for integrity protection may be computed over plain text data, ciphered data, and/or all or part of the PDCP header.

Encryption may be performed on the entire message containing the MAC words, and/or the plain text message and/or portions thereof.

Ciphering may also be performed on all or part of the PDCP header, e.g., a header that does not include a SN.

An indication of whether the payload has been encrypted and/or integrity protected may be included. For example, the PDCP layer 610 at the transmitting side may include an IE indicating that integrity check information and/or ciphering are activated. The indication may be encrypted. The indication may indicate a location of a MAC word in a message checked at the PDCP layer. The PDCP layer 610 at the receiving side may use the indication to decide whether to decrypt and/or integrity check.

The PDCP layer 610 and protocol may include MAC words for receiver integrity checking at predetermined locations in the PDCP header/message. Alternatively, the MAC word position may be indicated to the receiving PDCP layer 610. Such an indication may be an offset field as in the header.

According to the order of security operations at the transmitting side, the receiving PDCP will first decrypt the incoming message and then verify its integrity, or first verify integrity and then decrypt the message. The security operations in the receiving unit preferably have the reverse order of the transmitting unit side. The location of the MAC word in the PDCP header/message may be aided by an indication field.

The PDCP layer 610 may decide whether ciphering and/or integrity protection is not satisfactory for a particular message. This means that the PDCP will determine whether the message has been correctly ciphered and/or integrity protected.

The PDCP layer 610 may indicate a security state of RRC layer messages passed to the RRC layer 620, e.g., whether the messages are received via ciphering and/or integrity protection. Or as another example, whether the integrity protection check was successful. The indication shown is implicit, that is, provided only in the event of an error, when the integrity protection check fails. The RRC layer 620 then determines whether the protection of the specific message is acceptable. When notified of an error, the RRC behavior may be defined as PDCP described in page 12, lines 9-25. Alternatively, or in addition, the RRC layer may inform the network of the failure of the integrity check by adding an information element (to the RRC message sent to the network) informing the network of the failure.

In the event of an error, the PDCP layer 610 may employ the steps described in the failure handling scenario above. If the RRC message is asn.1 encoded and the MAC word is contained in the RRC layer 620, the PDCP layer 610 may observe the RRC layer and check the MAC word. If the flag indicating integrity protection is set, the PDCP layer 610 performs this.

Cross-layer security procedures

The RRC/PDCP layer may receive e-NB/RRC/U plane keys from the NAS layer or from the USIM. Alternatively, the RRC/PDCP may generate its own key. For example, the RRC layer may use parameters received from the network in RRC signaling and K received from NAS_ASMEAnd generating e-NB/RRC/U plane keys from other parameters received from other protocol layers (i.e., physical cell identities of cells to which the WTRU currently belongs or from which the physical layer has access). These security keys may be delivered between the NAS and the RRC/PDCP or between the RRC and PDCP using predetermined primitives, including new or existing primitives, on new or existing SAPs. Each layer may have the ability to indicate an error, i.e. a security failure, to the upper/lower layers.

Fig. 7 is a block diagram of a wireless communication system 700 configured for encrypted and unencrypted messaging in LTE. The system includes a base station 705 and a Wireless Transmit Receive Unit (WTRU) 710. The base station 705 and the WTRU 710 communicate via a wireless communication link.

As shown in fig. 7, the WTRU 710 includes a transmitter 720, a receiver 730, and a processor 740. Processor 740 is attached to buffer 750 and memory 760. The processor 740 is configured to process NAS messages containing security parameters using at least one of the techniques described above.

Also as shown in fig. 7, base station 705 includes a transmitter 765, a receiver 770, and a processor 780. Processor 780 is attached to buffer 790 and memory 795. The processor 780 is configured to process NAS messages containing security parameters using at least one of the techniques described above.

Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. The methods or flow charts provided in the present invention may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of the computer readable storage medium include Read Only Memory (ROM), Random Access Memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM optical disks and Digital Versatile Disks (DVDs).

For example, suitable processors include: a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any Integrated Circuit (IC), and/or a state machine.

A processor in association with software may be used to implement a radio frequency transceiver for use in a Wireless Transmit Receive Unit (WTRU), User Equipment (UE), terminal, base station, Radio Network Controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a video phone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, and BluetoothModule, Frequency Modulation (FM) radio unit, Liquid Crystal Display (LCD) display unit, Organic Light Emitting Diode (OLED) display unit, digital music player, media player, video game module, interconnectionA web browser and/or any Wireless Local Area Network (WLAN) module.

Examples

1. A wireless transmit/receive unit (WTRU) configured to implement security in Long Term Evolution (LTE) wireless communications, the WTRU comprising:

a receiver configured to receive a non-access stratum (NAS) message, the NAS message containing security parameters; and

a processor configured to:

determining whether the security parameter is correct; and

a security procedure is performed based on the determination.

2. The WTRU of embodiment 1, wherein the processor comprises:

a ciphering Radio Resource Controller (RRC) engine; and

the NAS engine is encrypted.

3. The WTRU as in any one of embodiments 1-2 wherein the processor comprises:

a ciphering engine configured to operate with RRC and NAS parameters.

4. The WTRU of embodiment 1, wherein the security procedure comprises at least one of: ignoring the message, discarding the message, reporting a failure to another protocol layer, initiating re-authentication, transitioning to an Evolved Packet System (EPS) mobility management (EMM Idle) mode, transitioning to an EMM _ deregistered state, maintaining a count of the number of failures, initiating reconnection to the network, and deleting the security parameter.

5. A method for implementing security in a Long Term Evolution (LTE) wireless device, the method comprising:

receiving a non-access stratum (NAS) message, the NAS message containing security parameters;

determining whether the security parameter is correct; and

a security procedure is performed based on the determination.

6. The method of embodiment 5, wherein the security procedure comprises at least one of: ignoring the message, discarding the message, reporting the failure to another protocol layer, initiating re-authentication, transitioning to an Evolved Packet System (EPS) mobility management (EMM Idle) mode, transitioning to an EMM _ deregistered state, maintaining a count of the number of failures, initiating reconnection to the network, and deleting the security parameter.

7. The method according to any of embodiments 5-6, wherein the NAS message contains a protocol header containing a NAS sequence number.

8. The method as in any one of embodiments 5-7, further comprising:

performing duplicate detection based on the NAS sequence number.

9. The method according to any of embodiments 5-8, wherein the NAS sequence number is used as a transaction identifier.

10. The method according to any of embodiments 5-8, wherein the NAS sequence number contains a predefined incrementing period.

11. The method as in any one of embodiments 5-8 wherein the NAS sequence number contains a negotiated incrementing period.

12. The method as in any one of embodiments 5-11 wherein the NAS message is related to a COUNT value.

13. The method of embodiment 12, wherein the COUNT value is used for ciphering (COUNT-C).

14. The method as in any one of embodiments 11-12 wherein the COUNT value is for integrity protection (COUNT-I).

15. The method of any of embodiments 11-14, wherein the COUNT value is a combination of COUNT-C and COUNT-I.

16. The method as in any one of embodiments 11-15, wherein the COUNT value comprises:

NAS Sequence Number (SN); and

NAS Hyper Frame Number (HFN).

17. The method as in any one of embodiments 11-16 wherein the NAS HFN is a counter.

18. The method as in any one of embodiments 12-17 wherein the COUNT value is used as an input to a ciphering integrity protection algorithm.

19. The method of embodiments 12-18, wherein the COUNT value is used as an input to a decryption integrity protection algorithm.

20. The method according to any of embodiments 12-19, wherein the COUNT value is configured prior to NAS security activation.

21. The method as in any one of embodiments 12-20 wherein the COUNT value is 32 bits or less.

22. The method as in any one of embodiments 16-21 wherein the SN and the HFN are configurable.

23. The method as in any one of embodiments 12-22 wherein the COUNT value is the NAS Sequence Number (SN) and duplicate detection is performed using the COUNT value.

24. The method as in any one of embodiments 5-23 wherein the NAS message indicates wireless transmit/receive unit (WTRU) capability information.

25. The method of embodiment 24 wherein the WTRU capability information indicates support for NAS level ciphering.

26. A method of implementing security in a Long Term Evolution (LTE) wireless device, the method comprising:

receiving a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU), the PDCP PDU including a security parameter;

determining whether the security parameter is correct; and

a security procedure is performed based on the determination.

27. The method of embodiment 26, further comprising:

sending an indication from a Radio Resource Controller (RRC) layer to a PDCP layer to indicate whether an RRC message requires at least one of integrity protection and ciphering.

28. The method as in any one of embodiments 26-27, further comprising:

sending an indication from the RRC layer to the PDCP layer to indicate that the RRC message to be transmitted does not require at least one of integrity protection and ciphering.

29. The method as in any one of embodiments 27-28, further comprising:

indicating to the PDCP layer that all RRC messages starting with a predetermined RRC message are to be ciphered or integrity protected.

30. The method as in any one of embodiments 27-29, further comprising:

indicating to the PDCP layer that all RRC messages starting with a predetermined RRC message are to be ciphered and integrity protected.

31. The method as in any one of embodiments 27-30, further comprising:

setting a ciphering or integrity check flag at the RRC to cipher or integrity check the RRC message.

32. The method of embodiment 31, further comprising:

in case that the ciphering flag is set, ciphering an RRC message before transmitting the RRC message as a PDCP PDU at the PDCP layer, and deciphering all received PDCP PDUs corresponding to the RRC message; and encryption and decryption are not performed in the case where the encryption flag is not set.

33. The method as in any one of embodiments 31-32, further comprising:

attaching a message authentication code to the PDCP PDUs corresponding to the transmitted RRC message and performing integrity check on all received PDCP PDUs mapped to the RRC message, in case the integrity check flag is set, and not performing the attaching and integrity check, in case the flag is not set.

34. The method as in any one of embodiments 27-33, further comprising:

setting a ciphering and integrity check flag at the RRC to perform ciphering and integrity check on the RRC message.

35. The method of embodiment 34, further comprising:

in case the ciphering and integrity check flag is set, ciphering an RRC message before transmitting the RRC message as a PDCP PDU, deciphering a received PDCP PDU corresponding to the RRC message, attaching a message authentication code to the PDCP PDU corresponding to the transmitted RRC message, and performing integrity check on all received PDCP PDUs mapped to the RRC message; whereas in case the flag is not set, no encryption, decryption, appending and integrity checking is performed.

36. The method as in any one of embodiments 27-35, further comprising:

providing the PDCP with a generic RRC message list and related security parameters of the RRC message.

37. A method as in any of embodiments 27-36 wherein the PDCP layer does not perform at least one of ciphering or integrity protection of RRC messages unless instructed to do so by the RRC.

38. The method as in any one of embodiments 27-37, further comprising:

encrypting the RRC message; and

and performing integrity protection on the RRC message.

39. A method as in any of embodiments 27-38 wherein the RRC message is padded to achieve an optimal length for ciphering or integrity protection.

40. The method as in any one of embodiments 26-39, further comprising: a Message Authentication Code (MAC) word is calculated for integrity protection on the plain text data, the ciphered data, the partial PDCP header or the entire PDCP header.

41. The method as in any one of embodiments 26-40 wherein the encrypting is performed on partial plaintext data.

42. The method as in any one of embodiments 26-41, further comprising: indicating whether the payload is encrypted or integrity protected.

43. The method as in any one of embodiments 26-42, further comprising:

a Message Authentication Code (MAC) word is predefined at a location in the PDCP PDU that contains a header.

44. The method of embodiment 43, wherein a predefined MAC word location is in the PDCP PDU header.

45. The method as in any one of embodiments 26-44, wherein the security procedure comprises at least one of: ignoring RRC messages, discarding the messages, reporting failures in failure reports, maintaining a count of the number of failures, and deleting the security parameters.

46. The method of embodiment 45 wherein the failure report includes a cause of the failure.

47. The method as in any one of embodiments 26-46, further comprising:

the PDCP Hyper Frame Number (HFN) is used to construct the COUNT value.

48. A method of implementing security in a Long Term Evolution (LTE) wireless device, the method comprising:

receiving a message at a Protocol Data Convergence Protocol (PDCP) layer;

decrypting the message; and

an integrity check is performed on the received message.

49. The method of embodiment 48 wherein the integrity check of the received message is performed prior to decrypting the message.

50. The method as in any one of embodiments 48-49, further comprising:

a position of a Message Authentication Code (MAC) word in the received message is determined.

51. The method as in any one of embodiments 48-50, further comprising:

it is determined whether encryption and integrity protection of the message is satisfactory.

52. The method as in any one of embodiments 48-51, further comprising:

indicating a security state of the received message to a Radio Resource Controller (RRC) layer.

53. The method as in any one of embodiments 48-52, further comprising:

sending an indication from the PDCP layer to a Radio Resource Controller (RRC) layer to indicate whether the integrity check on the received RRC message failed.

54. The method as in any one of embodiments 48-53, further comprising:

sending an indication from the PDCP layer to a Radio Resource Controller (RRC) layer to indicate whether the integrity check on the received RRC message was successful.

55. The method as in any one of embodiments 48-54, further comprising:

sending an indication of the integrity check failure from the PDCP layer to a Radio Resource Controller (RRC) layer only if a predetermined number of failures occur within a predetermined time interval or in a predetermined number of received RRC messages.

56. The method as in any one of embodiments 48-55, further comprising:

checking a Message Authentication Code (MAC) word in a Radio Resource Controller (RRC) layer of the PDCP when the received message is an ASN.1 encoded message.

57. The method as in any one of embodiments 48-56 wherein enforcing security comprises at least one of: ignoring the message, discarding the message, reporting the failure in a failure report, maintaining a count of the number of failures, and deleting the security parameter.

58. The method of embodiment 57, wherein the failure report includes a reason for the failure.

59. A method for key processing in a wireless transmit/receive unit (WTRU) upon a transition from an EMM _ Connected mode to an EMM _ Idle mode, the method comprising:

indicating the transition to a storage entity in the WTRU; and

the first group key is deleted.

60. The method of embodiment 59, further comprising:

the NAS security keys and ASME keys are retained.

61. The method as in any one of embodiments 59-60, further comprising:

the NAS security key and ASME key are deleted.

62. A method as in any of embodiments 59-61 wherein the indication is provided by a non-access stratum (NAS).

63. A method as in any of embodiments 59-62 wherein the indication is provided by an access stratum (NAS).

64. The method as in any one of embodiments 59-63 wherein the indication is provided using a predetermined primitive.

65. The method as in any one of embodiments 59-65 wherein the indication is provided when a serving e-NB changes in EMM _ Idle mode.

66. The method as in any one of embodiments 59-66 wherein the first group key comprises at least one of: k_eNB、K_RRCenc、K_RRCintAnd K_UPenc。

67. The method as in any one of embodiments 59-67 wherein the storage entity deletes K upon receiving the indication_eNB、K_RRCenc、K_RRCintAnd K_UPenc。

68. The method as in any one of embodiments 59-68 wherein the storage entity deletes K upon receiving the indication_eNB。

69. The method as in any one of embodiments 59-69, further comprising:

generating a second group key upon receiving the indication.

70. A method as in any of embodiments 59-70 wherein the indication is indicative of a change in the serving cell.

71. The method as in any one of embodiments 59-71 wherein the first group key comprises a timer value.

72. The method as in any one of embodiments 5-72, further comprising:

the key is received from the NAS layer or from the USIM.

73. The method of embodiment 72 wherein the received key is passed between the non-access (NAS) layer and RRC/PDCP layer using predetermined primitives.

74. A method as in embodiments 73-75 wherein a received key is transferred between RRC and PDCP using predetermined primitives.

Claims (16)

1. A method for performing a non-access stratum, NAS, security procedure in wireless communications, the method comprising:

performing an integrity check on a NAS message by using a COUNT value as an input to an integrity algorithm, wherein the NAS message comprises a NAS sequence number, NAS SN, and the COUNT value comprises the NAS SN and a NAS counter that is incremented by one each time the NAS SN is incremented by a certain number;

discarding the NAS message in response to the received NAS message failing the integrity check; and

processing the NAS message in response to the received NAS message passing the integrity check.

2. The method according to claim 1, wherein the NAS message further comprises a message header comprising a protocol discriminator, a message type octet and a half octet, wherein the half octet is used as a transaction identifier TI or a sub protocol discriminator.

3. The method of claim 1, wherein the NAS SN is in a protocol header of the NAS message.

4. The method of claim 1, wherein the NAS SN is received as the content of an information element, IE.

5. The method of claim 2, wherein the TI serves as the NAS SN.

6. The method of claim 1, wherein the NAS SN has a predefined increment period or a negotiated increment period.

7. The method of claim 1, wherein the COUNT value is increased on a predefined basis or a negotiated basis.

8. The method of claim 1, further comprising performing at least one of: reporting the failure to another protocol layer, initiating re-authentication, transferring to evolved packet system EPS mobility management EMM _ idle mode, transferring to EMM _ deregistered state, maintaining a count of the number of failures, starting to reconnect to the network, and deleting the security parameters.

9. An apparatus for performing a non-access stratum (NAS) security procedure in wireless communications, the apparatus comprising:

means for performing an integrity check on a NAS message by using a COUNT value as an input to an integrity algorithm, wherein the NAS message comprises a NAS sequence number, NAS SN, and the COUNT value comprises the NAS SN and a NAS counter that is incremented by one each time the NAS SN is incremented by a certain number;

means for discarding the NAS message in response to the NAS message failing the integrity check; and

means for processing the NAS message in response to the NAS message passing the integrity check.

10. The apparatus of claim 9, wherein the NAS message further comprises a message header comprising a protocol discriminator, a message type octet and a half octet, wherein the half octet is used as a transaction identifier TI or a sub protocol discriminator.

11. The apparatus of claim 9, wherein the NAS SN is in a protocol header of the NAS message.

12. The apparatus of claim 9, wherein the NAS SN is received as content of an information element, IE.

13. The apparatus of claim 10, wherein the TI serves as the NAS SN.

14. The apparatus of claim 11, wherein the NAS SN has a predefined increment period or a negotiated increment period.

15. The apparatus of claim 9, wherein the COUNT value is incremented on a predefined basis or a negotiated basis.

16. The apparatus of claim 9, further comprising means for performing at least one of: reporting the failure to another protocol layer, initiating re-authentication, transferring to evolved packet system EPS mobility management EMM _ idle mode, transferring to EMM _ deregistered state, maintaining a count of the number of failures, starting to reconnect to the network, and deleting the security parameters.