Method and apparatus for providing authentication in a communication system
Abstract
A method includes receiving an authentication request from a mobile station (401) and determining whether to forward the request to an authentication agent. When it is determined to forward the request, the request is forwarded to the authentication agent (107). A random number and a random seed are received from the authentication agent (107). The random number and the random seed are forwarded to the mobile station (401). A response to the random number and the random seed from the mobile station (401) is received and forwarded to the authentication agent (107). The authentication agent (107) compares the response with an expected response. When the authentication agent (107) authenticates the mobile station (401), a derived cipher key is received from the authentication agent (107).

Term
Term ended
Projected expiry passed 18 January 2022, 4.7 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
16 claims: 3 independent, 13 dependent
- 1CLAIMS REIVINDICAÇÕES 1 - Process comprising the steps of:1 - Processo que compreende os passos de: generating a random number, an expected response, and a derived cipher key associated with protected air interface communications with a mobile station (401, 403, 405);gerar um número aleatório, uma resposta esperada, e uma chave de cifra derivada, associada a comunicações protegidas de interface de ar com uma estação móvel (401, 403, 405);enviar o número aleatório e uma origem aleatória para a estação base (115, 117), que está localizada num primeiro conjunto de dispositivos, em que o primeiro conjunto esta associado a uma intra-chave utilizada para cifrar material de chave que é distribuído dentro do primeiro conjunto;send the random number and a random origin to the base station (115, 117), which is located in a first set of devices, wherein the first set is associated with an intrakey used to encrypt key material that is distributed within the first set;receber da estação base (115, 117) uma resposta ao número aleatório e à origem aleatória;receiving from the base station (115, 117) a response to the random number and random origin;comparar a resposta com a resposta esperada;e quando a resposta coincide com a resposta esperada, cifrar a chave de cifra derivada utilizando a intra-chave e enviar a chave de cifra derivada cifrada para a estação base (115, 117) . compare the answer with the expected answer;and when the response coincides with the expected response, encrypt the derived cipher key using the intrakey and send the encrypted derived cipher key to the base station (115, 117).
- 1010 A process performed by any of the base stations (115, 117), which is located on a first set of devices and comprises the steps of:10 - Processo executado por qualquer uma das estações base (115, 117), que está localizada num primeiro conjunto de dispositivos e que compreende os passos de: receber um pedido de autenticação de uma estação móvel (401, 403, 405);receive an authentication request from a mobile station (401, 403, 405);determinar se envia o pedido para um agente de autenticação;determine if it sends the request to an authentication agent;36 1 362 452 / EN ΕΡ 1 362 452 /PT 3/4 quando é determinado enviar o pedido, enviar o pedido para o agente de autenticação;3/4 when it is determined to send the request, send the request to the authentication agent;receber um número aleatório e uma origem aleatória do agente de autenticação;receive a random number and a random origin from the authentication agent;enviar o número aleatório e a origem aleatória para a estação móvel (401, 403, 405);send the random number and random origin to the mobile station (401, 403, 405);receber uma resposta para o número aleatório e para a origem aleatória da estação móvel (401, 403, 405) e enviar a resposta para o agente de autenticação;receive a response to the random number and random origin of the mobile station (401, 403, 405) and send the response to the authentication agent;quando o agente de autenticação autentica a estação móvel (401, 403, 405), receber do agente de autenticação uma chave de cifra derivada, que é cifrada utilizando uma intrachave, associada ao primeiro conjunto e utilizada para cifrar o material de chave de cifra que é distribuído dentro do primeiro conjunto;e cifrar as mensagens para a estação móvel (401, 403, 405) e decifrar as mensagens da estação móvel (401, 403, 405) com a chave de cifra derivada. when the authentication agent authenticates the mobile station (401, 403, 405), it receives from the authentication agent a derived cipher key, which is encrypted using an intrachakey associated with the first set and used to encrypt the cipher key material which is distributed within the first set;and encrypting the messages to the mobile station (401, 403, 405) and decrypting the messages from the mobile station (401, 403, 405) with the derived cipher key.
- 1515 A process performed by a base station which is located on a first set of devices and comprises the steps of:15 - Processo executado por uma estação base que está localizada num primeiro conjunto de dispositivos e que compreende os passos de: receber um número aleatório de uma estação móvel;receive a random number from a mobile station;enviar o número aleatório para um agente de autenticação;send the random number to an authentication agent;receber uma resposta para o número aleatório e para uma origem aleatória do agente de autenticação;receive a response to the random number and random source from the authentication agent;enviar a resposta e a origem aleatória para a estação móvel;send the response and random origin to the mobile station;quando a estação móvel autentica a infra-estrutura, que compreende o agente de autenticação e a estação base, enviar uma mensagem autenticada para o agente de autenticação;when the mobile station authenticates the infrastructure, which comprises the authentication agent and the base station, sends an authenticated message to the authentication agent;receber do agente de autenticação uma chave de cifra derivada, que é cifrada utilizando uma intra-chave, associada ao primeiro conjunto e utilizada para cifrar o material de chave, que é distribuído dentro do primeiro conjunto;receiving from the authentication agent a derived cipher key, which is encrypted using an intrakey, associated with the first set and used to encrypt the key material, which is distributed within the first set;cifrar as mensagens para a estação móvel e decifrar mensagens de uma estação móvel com uma chave de cifra derivada. encrypt messages to the mobile station and decrypt messages from a mobile station with a derived cipher key.
Independent claims3
171 paragraphs in 13 sections, as filed
DESCRIPTION
Method and apparatus for providing authentication in a communications system
Field of the invention
This invention relates to encrypted communications, including but not limited to air interface communication within secure communication systems.
Background of the Invention
Encrypted voice and data systems are well known. Many of these systems provide secure communication between two or more users by partitioning a piece of information between users, which only allows those users to know it to properly decipher the message. This piece of information is known as the variable cipher key, or shorthand key. 0 Carrying this key into the effective encryption device on the secure communications unit is a basic requirement that enables secure communication to occur. To retain security over a long period of time, keys are changed periodically, usually from week to week or from month to month.
Encryption is known to be performed on an end-to-end basis within a communications system, that is, by encrypting a message in the originating communication unit (also known as the mobile station) by passing it transparently ( without decryption) through any number of channels and / or parts of the infrastructure to the end-user communications unit, which decrypts the message.
The Terrestrial Trunked Radio (TETRA) communications standard is currently used in Europe (hereinafter the TETRA standard), with potential for expansion anywhere. The TETRA standard calls for an air interface, also known as air or air traffic cipher. The interface cipher of
36 1 362 452 / EN air protects information at the air interface between the infrastructure and the mobile subscriber. The TETRA standard requires an authentication center, also known as a key management service or key management center, to generate, distribute, and authenticate encryption keys and users. However, the TETRA standard does not specify how to implement an authentication center, nor how to generate, distribute, and authenticate key material for system devices or mobile stations for information traversing through the infrastructure or SwMI. as referred to in the TETRA standard.
The TETRA standard fails to provide definition to minimize load for bandwidth and call processing, provides encryption and authentication in a fault tolerant manner, supports wide area communications, and for storing keys for all units. communications without charge of improper storage at local sites.
Accordingly, there is a need for a process and apparatus for providing a secure infrastructure for a communications system that uses the air interface cipher and manages, distributes and authenticates cipher keys and users without unduly burdening the user. call processing, bandwidth, security, and storage.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram of a secure communication system according to the invention.
FIG. 2 is a block diagram showing key distribution assemblies according to the invention.
FIG. 3 and FIG. 4 are block diagrams showing key storage within a communication system according to the invention.
36 1 362 452 / EN
FIG. 5 is a diagram showing the distribution of authentication and key storage information within a communications system according to the invention.
FIG. 6 is a diagram showing storing authentication information and authentication decision making within a communications system according to the invention.
FIG. 7 is a diagram showing authentication of a mobile station by an authentication center according to the TETRA standard.
FIG. 8 is a diagram showing the authentication of an authentication center by a mobile station according to the TETRA standard.
FIG. 9 is a diagram showing the distribution of authentication and key storage information between a communications system and a mobile station according to the invention.
FIG. 10 is a diagram showing an output key within a communications system according to the invention.
FIG. 11 is a diagram showing an input key within a communications system according to the invention.
FIG. 12 is a diagram showing the distribution of a static encryption key to a base station within a communications system according to the invention.
FIG. 13 is a diagram showing the distribution of a static encryption key to a mobile station within a communications system according to the invention.
FIG. 14 is a diagram showing the distribution of a common cipher key to a mobile station and a base station within a communications system according to the invention.
36 1 362 452 / EN
FIG. 15 is a diagram showing the distribution of a group cipher key to a base station within a communication system according to the invention.
FIG. 16 is a diagram showing the distribution of a group cipher key to a mobile station within a communications system according to the invention.
FIG. 17 is a flowchart showing a key persistence process at a site in a communication system according to the invention.
Description of a preferred embodiment
The following describes an apparatus for and a method of providing a secure infrastructure for a communications system that uses air interface cipher and generates, distributes, and authenticates cipher keys and users without generating load. improper handling of call, bandwidth, security, and storage. System devices are divided into groups or sets and cipher keys are defined to provide secure transfer of key material between system devices.
A block diagram of a secure communications system including a large number of zones is shown in FIG. 1. Secure communications system includes a large number of system devices, including system infrastructure. A key management service (KMF) 101 transfers security data, such as session authentication information and cipher keys, to a user configuration server (UCS) 103, which sends the information and data to the appropriate supported zone. configuration data within UCS 103. Communications for a first zone are provided by a large number of system devices including a zone administrator (ZM) 105, a zone controller 107 including a home position location register (HLR) 109 and a visited location register ( also known as visitor or visitors) (VLR) 111, an air traffic forwarder (ATR) 113, and a large number of base stations (BS) 115, and
36 1 362 452 / EN
117 located at a large number of communication sites within the first zone. Communications for a second zone are provided by a large number of system devices including a ZM 119, a ZC 121 including an HLR 123 and a VLR 125, an ATR 127, and a large number of BS 129 and 131 located in a large number of communication sites within the second zone. BS 115, 117, 129, and 131 communicate with a large number of mobile stations (see FIG. 4). ZCs 107 and 121 communicate over a network 133, such as a local area network or a wide area network such as an Internet Protocol (IP) network. Only two zones and their associated system devices are shown for simplicity, although any number of zones can be successfully incorporated into the secure communications system.
For simplicity, not all system devices will be shown in each figure, but only a representative set of system devices illustrating a special concept will be provided. Similarly, not all key material is shown stored on each system device for space reasons. Each message containing a key, key material, configuration, or other information is transferred with a related identity (ID) such as ITSI or GTSI, although the ID is not generally shown in the drawings for consideration of space.
KMF 101 is a secure entity that stores the authentication key (K) for each mobile station (MS) or communications unit, such as a portable or two-way mobile radio, Direct Mode Operation (DMO) input, receiver, scanner, or transmitter (for example, see devices 401, 403, and 405 in FIG. 4). KMF 101 provides a random source (RS) and associated session authentication keys (KS and KS ') for each mobile station associated with the secure communications system. KMF 101 also imports / generates various air interface keys, such as static cipher key (SCK), group cipher key (GCK), and common cipher key (CCK) for distribution to the system. KMF 101 acts as the authentication center (AuC) as referred to in the TETRA communication standard in the system. Typically there is
36 1 362 452 / EN one KMF server per system, although there may be one or more KMF clients per system.
UCS 103 is a single point of entry for configuration data in the system. In the preferred embodiment, UCS 103 stores and distributes session authentication information, such as RS, KS, and KS ', to the appropriate home position zone in the system. UCS 103 acts as a non-realtime distribution point for system session authentication information.
ZM 105 or 119 is an administration database for a zone. In the preferred embodiment, ZM 105 or 119 stores session authentication information, such as RS, KS, and KS ', for the zone administered by special ZM 105 or 119. ZM functions as a non-real time storage service for authentication information in the zone.
The ZC 107 or 121 performs real-time authentication for mobile stations in its zones. ZC uses session authentication information, such as RS, KS, and KS ', to perform real-time authentication. HLR 109 or 123 stores session authentication information for each MS that has HLR 109 or 123 in its home position. VLR 111 or 125 stores session authentication information for each MS by visiting the zone of VLR 111 or 125. ZC 107 or 121 performs real-time distribution of its session authentication information from home position mobile stations when the MS re-addresses outside its home position zone. In the preferred embodiment, an HLR 109 or 123 and VLR 111 or 125 are part of each zone controller and act on behalf of the same zone to which the zone controller is associated. HLR 109 or 123 and VLR 111 or 125 may be part of other system devices or may be stand alone devices. The derived cipher key (DCK) is generated during authentication. ZC 107 or 121 generates and distributes DCK for MS for BS 115, 117, 129, and 131 requiring DCK for secure communications.
ATR 113 or 127 is the channel used by KMF 101 to send key retry messages or key updates to an MS, such as SCK or GCK. KMF 101 sends
36 1 362 452 / EN mobile station key upgrades to home position zone ATR 113 or 127 for dissemination. All key repeat ratios (ACKs) originating from infrastructure e and MS pass through ATR 113 or 127 to KMF 101.
Each BS 115, 117, 129, and 131 receive and transmit authentication messages over an air interface. Each BS 115, 117, 129, and 131 acts as a transmitter for its associated ZC 107 or 121 and as a receiver for the MS in the system. BS 115, 117, 129, or 131 uses DCK for air interface encryption with MS. BS 115, 117, 129, and 131 are responsible for sending key material to MS 401, 403, 405, and 407. The result of some of these operations (SCK, GCK) is sent back to KMF 101. Because each base site includes substantially one or more base stations, the terms base site (or site) and base station are used interchangeably herein, both apportioning the acronym BS. In the preferred embodiment, a TETRA site controller (TSC) connects all base stations in one site, stores key material, and distributes key material to base stations as needed, thus making keys available to all base stations. in one place. Thus, when a key is said to be stored at a base station or base site, in the preferred embodiment, the TSC effectively provides storage for the base station for key material. Because key storage and distribution and other key related functions may be performed by a base site, base station, or TSC, these terms are considered interchangeable for the purposes of this document.
The mobile station (MS) authenticates the system and / or is authenticated by the system using an opposing protocol. Each MS has its own key, K, to use during authentication. Each MS is assigned to an HLR, which typically remains the same. Each MS is also associated with only one VLR in a zone in which the MS is now located. An MS is not registered on a system until the MS is active and has passed authentication.
36 1 362 452 / EN likelihood of compromise
FIG. 2 is a block diagram showing key distribution sets. Using a single key encryption key (KEK) to encrypt keys for large distribution systems is a convenient choice, although a single KEK would result in degraded security due to the higher that KEK would be compromised and the resulting system-wide impact . Using a different KEK for each system device would be safer, but would load storage within system devices and add unnecessary delays to call processing. FIG. 2 shows a system for using KEK that is more secure than a single wide-key system, yet not as cumbersome as a different KEK for each system device. Two types of KEK are assigned to confidentially distributed key material (such as air interface keys, session authentication information, data used to generate cipher keys, and other key related material) from one of 80 to the other. system devices: intra-keys and bits in the system implementation of inter-key infrastructure. KEKs are preferred.
The first type of KEK is an intrakey, also referred to as an intra-set key or intrazone key KEK.<sub>Z</sub>. System devices are divided into sets or groups 201, 203, 205, and 207. Each set is assigned its unique key KEK.<sub>Z</sub>. In the preferred embodiment, each set of devices corresponds to a zone in the communications system, and each set has a mutually exclusive collection of system devices, that is, each system device belongs to only one set. First Set 201 Uses KEK<sub>Z1</sub> to encrypt key material, such as encryption keys and / or session authentication information, to transfer within the first set (or zone in the preferred embodiment) and includes the first zone controller ZCl 107 and its associated BS 115, 117, and 211. The second set 203 uses KEK<sub>Z2</sub> for encrypting the transferable key material within a second set (or zone in the preferred embodiment) and comprises the second zone controller ZC2 121 and its associated BS 129, 131, and 213. The third set 205 utilizes KEK<sub>Z3</sub> to encrypt the key material to
Transfer within the third set (or zone in the preferred embodiment) and includes the third zone controller ZC3 223 and its associated BS 225, 227, and 229. The fourth set 207 uses KEK<sub>Z4</sub> for encrypting key material for transfer within the fourth set (or zone in the preferred embodiment) and includes the fourth zone controller ZC4 215 and its associated BS 217, 219, and 221. In the preferred embodiment, the intrakey is used by a zone controller for distributing key material to base sites / base stations within its zone. The KEK<sub>Z</sub> It is also used by KMF 101 to distribute SCK.
KEK's second type is a KEK interkey<sub>M</sub>, also referred to as an inter-set key or inter-zone key. The key is used to encrypt key material sent between sets or zones in the preferred embodiment, or within a certain group of system devices 209, particularly from KMF 101. In the preferred embodiment, the key is used by KMF 101 to distribute GCK and individual authentication information to the infrastructure. In the preferred embodiment, the intrakey is stored on a system device in each zone on each zone controller 107 and 121, and is also stored on KMF 101. The connections shown between KMF 101 and zone controllers 107, 121 , 215, and 223 are virtual links in the preferred embodiment, wherein other devices, such as UCS 103 and ZM 105 and 119, are physically located between KMF 101 and zone controllers 107, 121, 215, and 223. UCS 103 and ZM 105 and 119 pass encrypted key information transparently between KMF 101 and zone controllers 107, 121, 215, and 223, i.e. UCS 103 and ZM 105 and 119 do not decrypt or encrypt the information, and thus no storage of a KEK is required in UCS 103 and ZM 105 and 119, although key material may be stored in encrypted form in UCS 103 and ZM 105 and 119.
Preferably, a message is encrypted by one of the intra-keys and inter-keys, typically using TA31 (deciphered using ο TA32), supported on a system device to which the message is sent. For example, when the message is directed to a system device in a different zone than the zone containing the
ΕΡ 1 362 452 / EN address, the inter-key is used. When the message is directed to a system device in the same zone as the zone containing the address device, the intrakey is used. In the preferred embodiment, when KMF 101 encrypts key material, such as SCK, CK, SAI, and GCK, with either inter-key or intra-key, KMF 101 uses TA31.
For example, from time to time, key material is distributed from the HLR to a VLR and then to the base sites within the VLR zone. In this case, the key material is encrypted by KEK<sub>M</sub> and passed transparently from HLR to VLR. Target VLR decrypts key material using its KEK<sub>m</sub> and makes the cipher the same with KEK<sub>Z</sub> zone for distribution to sites within the zone.
Each system device containing a KEK infrastructure has its own unique infrastructure or protection key, Kl, in the preferred embodiment. The protection key is only used to decrypt / encrypt KEK sent by KMF 101 to infrastructure system devices. Preferably, the Kl is only capable of being carried by a variable key loader and is not capable of being updated with an over-the-air key repeat operation - OTAR. In addition to the distribution by KMF 101, KEKs can also be supplied manually with a variable key loader. K1 has a length of 128 bits in the preferred embodiment.
As shown in Table 1 below, KEK<sub>M</sub> it is only stored by zone controllers 107 and 121 and KMF 101. The intrakey KEK<sub>Z</sub> is maintained only by KMF 101, base sites / stations, and zone controller 107 and 121 within each zone. Each zone has a unique KEK<sub>Z</sub>. Each seismic device has its own Kl.
36 1 362 452 / EN
Table 1
<td colspan="3">DISTRIBUTION OF KEY Cipher KEY TYPES</td>
<td>INFRASTRUCTURE ELEMENT</td><td>ZONE 1</td><td>ZONE 2</td>
<td>Zone Controller (HLR, VLR)</td><td>KI<sub>4</sub>, KEK<sub>m</sub>, KEK<sub>Z</sub>i</td><td>KI<sub>2</sub>, KEK<sub>m</sub>, KEK<sub>z2</sub></td>
<td>Base Sites</td><td>KI<sub>3</sub>, KEK<sub>Z1</sub></td><td>KI<sub>4</sub>, KEK<sub>z2</sub></td>
The use of intra-keys and inter-keys meets a unique tradeoff between security and complexity of key management as well as the speed of call processing. KMF 101 needs to keep only one interkey plus one intrakey for each set or zone in the system. If a KEK<sub>Z</sub> is compromised, preference and response are located in that zone rather than the entire system, and Kl remains intact to redistribute a new KEK<sub>Z</sub> to that zone. The KEK<sub>M</sub> It is stored only in KMF 101 and HLR 109 and 123 and VLR 111 and 125 in each zone, which devices are typically more physically protected from attack. If KEK<sub>M</sub> is compromised, KMF 101 alters KEKm on ZC 107 and 121, leaving sites unaffected.
Five basic types of air interface keys are used to encrypt air interface traffic in the secure communications system: a static cipher key (SCK), a common cipher key (CCK), a group cipher key (GCK) ), a derived cipher key (DCK), and a modified group cipher key (MGCK). Three basic types of keys are used between system devices: an infrastructure key (Kl) also known as a protection key, an inter-zone or inter-set key cipher key also known as an inter-key (KEK<sub>M</sub>), and an intra-zone or intraset key cipher key also known as an intrakey (KEK<sub>Z</sub>) .
The static encryption key (SCK) is the most basic of air interface keys and is used to encrypt information within the subject (MS for infrastructure) and outside the subject (infrastructure for MS) when authenticating. and / or dynamic air interface cipher is not
ΕΡ 1 362 452 / EN available. Thus, the generation and distribution of this key has nothing to do with authentication.
The derived cipher key (DCK) is a derived session key within the authentication procedure. DCK changes each time an authentication is performed with MS and infrastructure, also called SwMI in the TETRA standard. DCK is used to encrypt traffic within the subject. DCK is also used for individually addressed out-of-subject traffic to MS. DCK is used when using dynamic air interface cipher operating in TETRA security class 3.
The common cipher key (CCK) is a group key in the sense that multiple MS have the same CCK. Unlike GCK, however, CCK has nothing to do with a special speech group (TG). CCK is geographically specific, ie CCK satisfies all units within a given location area. The location area as defined in the TETRA standard can be as small as a site or large as an entire system. Each unit within a location area uses the same CCK. Out-of-subject group communications use CCK when there is no GCK / MGCK available for that group call. CCK is used for ciphering out-of-subject group traffic and identities only. Identities within the subject are encrypted with CCK when DCK is in use.
Indirectly, the group cipher key (GCK) is used to encrypt speech group calls outside the subject. In the preferred embodiment, a GCK is defined for each speech group in the system. In fact, GCK is only indirectly used for traffic information encryption; The modified group cipher key (MGCK), which is a derivation of GCK, is directly used for traffic encryption. GCK is never used for the current traffic cipher as it is considered a long term key.
The modified group cipher key (MGCK) is used to encrypt out-of-subject speech group call traffic. MGCK is formed by the combination of GCK and CCK.
36 1 362 452 / EN
Each GCK has a corresponding MGCK defined for a location area.
Each infrastructure element has an infrastructure or protection key, Kl, which is used as the cipher key for any infrastructure key cipher key updates. Kl is similar in function of the authentication key, K, in a mobile station. In the preferred embodiment, the Kl is updated only by a supply device such as a variable key loader. In the preferred embodiment, Infrastructure Key Decryption (KEK) key updates cannot be performed without this key.
Each zone controller has one KEK key<sub>M</sub>, also referred to as an inter-zone or inter-set key, which is used to encrypt all key traffic passed between KMF and each zone. The KEK<sub>M</sub> It is also used by the zone controller to pass GCK, CCK, and DCK, as well as session authentication information between zones. In the preferred embodiment, a KEK is present.<sub>M</sub> KMF and each of the zone controllers in each system.
Each zone has its own key KEK<sub>Zf</sub> also referred to as an intra-zone or intra-set key. Intrakey is used to encrypt all key traffic within the zone between the zone controller and each of the sites within the zones. Each base site and zone controller has the same KEK<sub>Z</sub> in a mess. 0 KMF stores the KEK<sub>Z</sub> for each zone in the system.
A process of the present invention establishes an expected lifetime, or key retry interval, for a cipher key. Table 2 below shows examples of key retry intervals for each key stored in the secure communications system. When the expected lifetime of a cipher key expires, that is, when the key retry interval occurs, the cipher key is replaced.
A number of storage locations for each type of system device within a storage system.
36 1 362 452 / EN communications is determined. For example, one KMF 101, one UCS 103, one ZM 105 or 119 per zone, one zone controller 107 or 121 per zone, one HLR 109 or 123 per zone, one VLR 111 or 125 per zone, and a number of sites and corresponding base stations per site depending on the coverage requirements for each zone. Based on the expected lifetime of each cipher key and the number of storage locations for each system device, a type of system device is assigned to store each cipher key, and cipher keys are stored on the system device. of the assigned type. For example, derived cipher keys are stored on base stations and HLR / VLR, common cipher keys are stored on base stations, modified group cipher keys are stored on base stations, and group cipher keys that are stored on base stations. stored in HLR and VLR.
Table 2 shows the target (user) of each key and the key retry interval, that is, the time between changes or updates of the specific key in a preferred embodiment. For example, MGCK, which is a combination of CCK and GCK, is updated each time the CCK is changed and the GCK is changed. Table 2 can be changed by the KMF operator.
Table 2
<td></td><td>KEY TARGET</td><td>KEY REPEAT INTERVAL</td>
<td>SCK</td><td>All MS, all BS</td><td>1 year / or if committed</td>
<td>DCK</td><td>MS, BS, HLR, VLR</td><td><24 hours whenever the unit authenticates</td>
<td>CCK</td><td>group (TG HLR), all MS, all BS</td><td>24 hours</td>
<td>GCK</td><td>group (TG HLR)</td><td>6 months</td>
<td>MGCK</td><td>group (BS, MS)</td><td>24 hours - Minimum of CCK, GCK range</td>
<td>KI</td><td>All devices using KEK<sub>Z</sub> or KEK<sub>M</sub> (BS, ZC)</td><td>Never change</td>
<td>KEK<sub>Z</sub></td><td>zone</td><td>6 months / or if compromised</td>
<td>KEK<sub>M</sub></td><td>system</td><td>6 months / or if compromised</td>
EP 1 362 452 / EN
There are PC-based software programs that enable both mobile station devices and keyed infrastructure system. A more secure process utilizes the capabilities of the Variable Key Loader (KVL) or, in short, key loader to load keys into infrastructure devices as well as MS. 0 Key loader has a physically backed encryption device to protect the keys stored within the device. KVL can obtain keys directly from KMF by acting as a warehouse and sending an active principle to disseminate key encryption keys to the various devices.
Although a KVL is a very secure way to provide keys, it is a time consuming process to use one or more KVL to provide keys on each system device and mobile station. A key management process is required to store and distribute KEKs and other key material to system devices such as zone controllers and base sites.
KMF 101 is responsible for the generation, key distribution, and tracking of most air interface switches (not DCK or MGCK) in the system. Base sites 115 and 117 and each zone controller 107 satisfy as a delegation to KMF 101 for key distribution. KMF 101 distributes key material to the zones via UCS 103, ZM 105 and 119, and / or ATR 113 and 127 depending on the key to be distributed. KMF 101 processes recognition information from ATR 113 and 127 to maintain general acceptance of system and MS devices 401, 403, 405, and 407. Fig. 3 and FIG. 4 show the storage of key material within the communications system.
As shown in Fig. 3, KMF 101 stores a protection key and associated KEK (s) for each system device. KMF 101 stores one protection key (infrastructure), one interkey, and one intrakey for each zone controller. For example, the first zone controller 107 is associated with KI keys.<sub>ZC</sub>i KEK<sub>M</sub>, and KEK<sub>Z1</sub>. KMF 101 stores these keys encrypted by a hardware key and the first zone controller 107 stores KI<sub>ZC</sub>ie
36 1 362 452 / EN as KEK<sub>m</sub> and KEK<sub>Z1</sub> encrypted. KMF 101 stores a protection key and intra key, both protected by a hardware key, for each BS. For example, KMF 101 and first BS 115 both store the protection key KI<sub>B</sub>si θ the intra key KEK<sub>Z1</sub>. In the preferred embodiment, KMF 101 stores encrypted keys / protected by a hardware key.
Prior to the distribution of a KEK in the preferred embodiment, KMF 101 encrypts KEK with the protection key, KI, and the use of algorithms and encryption TA41 and TA51, similar to those shown in FIG. 10 entitled Distribution of SCK to an individual by an authentication center and its associated text on TETRA; Voice plus Data (V + D); Part 7: Safety, EN 300 392-7
V2.1.1, 2000-12 (referred to herein as the TETRA Standard).
KMF 101 stores an encryption process 301 that combines RSO and the appropriate KEK, KEKN, and KEK-VN using encryption algorithms TA41 303 and TA51 305, developing SKEK, which is a sealed version of KEK. RSO, SKEK, KEKN, and KEKVN are directed to the target system device. Wavy parentheses {} followed by a key name indicate that material within the wavy parentheses was created using TA41 and TA51 and the key name after the parentheses.
For example, KEK<sub>Z1</sub> is intended to be transferred to the first zone controller 107 and BS1 115. The RSO, KEK<sub>Z1</sub>, KEK<sub>Z1</sub>-VN, and KEK<sub>Z1</sub>N, and KI<sub>ZC1</sub> are combined using TA41 and TA51 cipher algorithms, developing the SKEK<sub>Z1</sub>. RSO, SKEK key materials<sub>Z1</sub>, KEK<sub>Z1</sub>-VN, and KEK<sub>Z1</sub>N are directed transparently through ZM1 105 to the first zone controller 107, which combines this key material with the KI<sub>ZC1</sub> using TA41 and TA51 (as described in the TETRA standard), developing the KEK<sub>zlf</sub> which is stored in ZC1 107. The RSO, KEK<sub>Z1</sub>, KEK<sub>Z1</sub>-VN, and KEK<sub>Z1</sub>N and KI<sub>BS</sub>i are combined using TA41 and TA51 cipher algorithms, developing SKEK<sub>Z1</sub>. RSO, SKEK key materials<sub>Z1</sub>, KEK<sub>Z1</sub>VN, and KEK<sub>Z1</sub>N are directed transparently through ZM1 105 to BS1 115, which combines these key materials with KI<sub>BS1</sub> using TA41 and TA51, developing the
EP 1 362 452 / EN
<td>KEK<sub>Z1</sub> O</td><td>what</td><td>is stored in</td><td>BS1 115.</td><td>At</td><td>embodiment</td>
<td>preferred</td><td>, one</td><td colspan="2">unencrypted recognition</td><td>in</td><td>reception with</td>
<td>success of 113</td><td>each</td><td>key is returned</td><td>for KMF</td><td> 101</td><td>through the ATR</td>
A block diagram showing key storage within a communications system is shown in FIG. 4. In particular, storage of session authentication information through the communications system is shown. In the preferred embodiment, the session authentication information includes a random source, RS, and two session keys, KS, for authentication of an MS and KS 'for infrastructure authentication, for each mobile station 401, 403, and 405. (Only three are shown due to space contingencies, although numerous MS are part of the system). Session authentication information (SAI) is used to generate a derived cipher key (DCK) for each MS 401.
For each MS 401, 403, and 405, KMF 101 stores an individual TETRA subscriber identity (ITSI), TETRA equipment identity (TEI), and an MS authentication key (MS key) that is unique and stored within each MS 401, 403, and 405. In the preferred embodiment, the air interface keys and MS keys are encrypted hardware using a hardware key K<sub>H</sub> within KMF 101. The DIV-XL algorithm, available from Motorola, Inc. is used to encrypt keys for storing in KMF 101 in the preferred embodiment. Square brackets [] followed by a key name indicate that material within square brackets is encrypted by that key.
KMF 101 generates session authentication information for each MS 401, 403, and 405, which SAI is at least partially encrypted and sent in real time to UCS 103 for storage. For each MS 401, 403, and 405, UCS 103 stores the ITSI, TEI, and HLR ID associated with each MS, as well as the SAI. In the preferred embodiment, KS and KS 'are stored encrypted by the key (as received from KMF 101) in UCS 103 for fast and easy transport, and RS is stored unencrypted. UCS 103 is a transparent device in the preferred embodiment, not running it
No encryption or decryption function. In order to eliminate a potential double entry of information, KMF 101 receives configuration information from UCS 103. Examples of configuration information are: individual TETRA subscriber identity (ITSI), group TETRA subscriber identity (GTSI), zone home position, and zone administrators. KMF uses a lookup table, such as a domain name server (DNS) lookup table, to obtain ATR addresses 113 and 127. The distribution of each of the different key types has different configuration requirements, as here. inside described.
UCS 103 sends the SAI to each ZM 105 in non-real time, supported by the HLR ID associated with each MS 401. ZM 105, like UCS 103, is a transparent device and performs no encryption or decryption function. The ZM 105 stores, for each MS that has HLR 109 as its home position location, an ITSI, TEI and SAI. In the preferred embodiment, KS and KS 'are stored encrypted by the key (as received from UCS 103) in the ZM 105 or 119 for easy and fast transport, and the RS is stored unencrypted.
ZM 105 sends the SAI to HLR 109 in non-real time. HLR 109 stores one ITSI and SAI for each MS 401, 40, and 405. In the preferred embodiment, KS and KS 'are stored encrypted by the key (as received from ZM 103) in HLR 109, and RS is stored. not encrypted. In the preferred embodiment, RS, KS, and KS 'are stored unencrypted in VLR 111 for faster authentication. In an alternative embodiment, KS and KS 'may be stored unencrypted in HLR 109 for faster authentication.
When an MS 401 is authenticated in the zone, a new DCK for MS 401 is generated by the VLR 111 on the real-time SAI zone controller 107, after any encrypted IAS is deciphered due to the transfer of the HLR IAS 109. (A ITSI, SAI, and previous DCK associated with that MS 401 are sent to VLR 111 in real time before the new DCK is created). ITSI, SAI, and the new DCK are sent to the HLR 109 in real time for storage. In the preferred embodiment, ITSI, SAI, and DCK come from HLR to MS 401, so this information may come from a different zone if MS 401 does not.
ΕΡ 1 362 452 / EN use the HLR 109 for your starting position. When the SAI / DCK comes from a different zone, that zone decrypts / encrypts the information as needed with the key to transport to the appropriate zone, which also provides the appropriate decryption / encryption within the zone. The DCK is stored encrypted by the KEK key.<sub>Z</sub> to the zone in which it is stored for quick and easy transport to local BS 115 or 117. In the example shown in FIG. 4, each DCK is stored encrypted by KEK<sub>Z1</sub>. In the preferred embodiment, KS and KS 'are always encrypted with the KEK key.<sub>M</sub>, for fast and easy transport during the authentication process, even when the transfer is within the same zone.
During the authentication process, the BS 115 communicating with the MS 401 receives from the ZC1 107 in real time the MS 401 DCK, encrypted by the intrakey KEK<sub>Z1</sub>. BS 115 stores unencrypted ITSI and DCK for immediate use while MS 401 is in the coverage area of BS 115. See FIG. 17 and its associated text for information for key persistence at each site.
Each MS 401, 403, and 405 stores its own ITSI, TEI, and DCK in unencrypted form, and K is stored in scrambled or encrypted form. Each MS 401, 403, and 405 also stores in unencrypted form CCK, GCK, MGCK, and SCK as they are received. These keys may be stored encrypted in the infrastructure in an alternative embodiment.
Zone controller 107 is responsible for real-time key distribution and mobility management of them. It keeps keys that may need to be distributed in a necessary way in real time when re-addressed, for example. The group cipher key is an element in each of the speech group registers and is kept in the HLR speech group. The common cipher key is a site or zone specific key and is also kept in the zone controller. ZC is responsible for the creation of MGCK (supported by GCK and CCK) and distribution to the sites.
Because the keys exist within the speech group and individual HLR 109, the zone controller 107 is not transparent with respect to the encryption of the key material. The ZC
36 1 362 452 / EN
107 holds one protection key, Kl, and two infrastructure key cipher keys, interkey KEK<sub>M</sub> and intra key KEK<sub>Z</sub>, for the distribution of key material. Kl is used to seal (encrypt) KEK<sub>M</sub> and KEK<sub>Zf</sub> when they are sent from KMF 101. Most key information is encrypted by the zone controller using the KEK<sub>M</sub> and
KMF 101 with 107 decrypts makes it encrypting interkey KEK<sub>M</sub>. The key material the same information using the KEK<sub>Z</sub> when sending information to a site within the zone. Thus, zone controller 107 has the TETRA algorithms used for encryption / decryption of infrastructure keys (such as TA41 and TA52 and TA31 and TA32) as described herein.
The zone controller sends infrastructure rekeying ACKs to KMF 101 via ATR 113. When a ZC 107 or HLR 109 receives a key update, the device first decrypts the key update and checks if There is a flaw in checking data integrity and sending the result of this operation to KMF 101 via ATR 113 in the form of an ACK.
The site is a terminal for air interface cipher. The audio at the air interface between BS 115 and MS 401 is encrypted. Audio within the infrastructure is not encrypted. Out-of-subject traffic is encrypted with algorithms using MGCK, CCK, and SCK, or DCK for individual calls. All traffic from within the subject is encrypted with algorithms using DCK or SCK. The site maintains the traffic and key storage algorithms for SCK, CCK, and MGCK, as well as DCK. Because the base site has traffic key storage, the base site is not transparent to the key material cipher. All key material distributed to the base site is encrypted by the intrakey KEK<sub>Z</sub>. Thus, the base site maintains a protection key, Kl, and an interkey KEK<sub>Z</sub>. Thus, the base sites have the TETRA algorithms used for encryption / decryption of infrastructure keys (such as TA41 and TA52 and TA31 and TA32) as described herein.
MS is the other endpoint for air interface cipher. Out-of-subject traffic is encrypted with algorithms using MGCK, CCK, and SCK, or DCK if individually.
36 1 362 452 / EN addressed. All traffic within the subject is encrypted with algorithms using DCK or SCK, and identities can be encrypted with SCK or CCK. MS maintains the traffic and key storage algorithms for SCK, CCK, GCK, and MGCK as well as DCK.
The following figures provide examples of the role of zone controller 107 or 121 in any of its key generation, key distribution, and authentication functions, as well as base site / base station and MS operations in key generation, key distribution, and key, and authentication processes.
A diagram showing an example of key storage and distribution of authentication information within a communications system is shown in FIG. 5. Session authentication information (RS, KS, and KS ') is required to facilitate MS 401 real-time authentication by ZC 107 and MS real-time system authentication as well as mutual authentication. Triggers for the transfer of IAS can be a manual initiation by the KMF operator, an automatic system activation trigger, or a periodic change of the IAS by KMF 101.
FIG. 5 shows the transfer of SAI to two mobile stations, ITSI1 401 and ITSI2 403 (both not shown). KMF 101 encrypts at least a portion of the SAI (for example, KS and KS ') with the KEK interkey<sub>M</sub> to the system, and sends KEK encrypted ITSI1, ITSI2, RS, KS and KS '<sub>M</sub> for UCS 103. UCS 103 stores a copy and sends it to the home position ZM 105 or 119 for each ITSI. Dashed lines within a system device indicate transparent passages of information through the system device. ZM 105 or 119 also stores a copy and sends it to your ZC107 or 121, especially HLR 107 or 123. ZC 107 or 121 stores encrypted KS and KS 'along with RS in HLR 107 or 123. Since the HLR 109 or 123 receives the SAI, an unencrypted acknowledgment (ACK) is sent when decrypting using KEK<sub>M</sub> fails, back to KMF 101 via ATR 113 or 127 from the zone in which HLR 109 or 123 exists. If a VLR 111 for MS 403 exists, such as ITSI2, the ZC 121 sends KS and KS 'encrypted with the KEK key.<sub>M</sub> VLR 111. No coordination is required between authentication session information
ΕΡ 1 362 452 / EN and a new authentication session information. HLR 109 or 123 only needs one copy of registered ITSI SAI. The UCS 103 and ZM 105 or 119 store copies of authentication session information to provide system recovery or maintenance.
By providing storing and sending session authentication information and keys in non-real time (i.e. unrestricted time) between first level system devices and real time (i.e. on demand) between second system devices At the level described above, the authentication system provides a fault tolerant system that also allows for rapid recovery from failure. If KMF 101, UCS 103, and / or ZM 105 and 119 fail or are separated from the rest of the system, full authentication can still be performed without interruption on a real time basis with session authentication information, for example for session authentication. MS2 403, stored at HLR 123 and VLR 111. A failure in either of these devices 101, 103, 105, and 119 is not catastrophic, in that stored data may be downloaded from any of the other devices that store the information. If a zone controller 107, HLR 109, and / or VLR 111 experiences a fault or fault, the SAI can be immediately downloaded from the ZM 105 in the zone. By eliminating the need for KMF 101 to participate in the authentication process in real time, there is less load on KMF 101 and less overall traffic on communications links between infrastructure system devices.
A diagram showing making the authentication decision and storing authentication information within a communications system is shown in FIG. 6. Four mobile stations are shown within a system where three mobile stations 401, 403, and 405 use HLR1 109 from the first zone controller 107, one mobile station 407 uses HLR2 123 from the second zone controller 121, two mobile stations 401 and 403 use VLR1 111, and two mobile stations 405 and 407 use VLR2 125. SAI storage is shown through system devices. Also shown are base station decisions whether or not to authenticate a mobile in a special activator. For example, call messages, whether encrypted or not, require authentication. Any message sent in the clear
36 1 362 452 / EN (ie unencrypted) requires authentication. Encrypted sent messages may be implicitly authenticated, that is, the response and challenge mechanism may be derived if the encrypted addressed message is successfully decrypted by BS 131. Connection messages, rerouted messages, location updates, and other message types. are considered requests to communicate within the communications system. When authentication is required, BS 115, 117, 129, or 131 sends a request to authenticate MS to the infrastructure (to a zone controller in the preferred embodiment). In the event that the infrastructure device to which authentication requests are sent becomes unavailable, for example, the device fails, is down for maintenance, or the communications link to the device is not operational, BS stores authentication requests for the period of time when the infrastructure device is unavailable. When the infrastructure device becomes available, for example, the device is returned to service after a failure or maintenance or when the communications link comes up, BS sends the stored authentication request to the infrastructure device. -structure.
In a situation shown in FIG. 6, a first MS 401 sends a clear (unencrypted) connection message to the first BS 115. In the preferred embodiment, authentication of the MS 401 is requested in this situation. Because the MS 401 uses HLR 109 in the zone where the BS 115 is located, SAI1 session authentication information for MS 401 is sent from HLR 109 to VLR 111 in the zone to complete the authentication process.
The second MS 403 reroutes from BSl 115 to BS2 117 and sends a clear (unencrypted) reroute message to the second BS 117. In this preferred embodiment, authentication of MS 403 is requested in this situation. Because MS 403 uses HLR 109 in the area where BS 115 is located, and because MS 403 re-addresses from a site assisted by the same VLR as the new site, SAI2 session authentication information for MS 403 is already located. VLR 111 in the zone to complete the authentication process.
36 1 362 452 / EN
The third MS 405 sends an encrypted link message to the third BS 129. In the preferred embodiment, authentication of the MS 405 is requested in this situation. Because MS 405 uses the HLR 123 in the zone where the BS 129 is located, the information Session authentication session for MS 405 is sent from HLR 123 to VLR 125 in the zone to complete the authentication process.
The fourth MS 407 is rerouted from BS2 117 to BS4 131 and sends an encrypted reroute message to the fourth BS 131. In the preferred embodiment, the (full) authentication of MS 403 is not requested. Instead, the MS 407 is implicitly authenticated, that is, the response and challenge mechanism is derived if the encrypted re-addressed message is successfully deciphered by BS 131. Because MS 407 uses HLR 109 in the zone other than that zone where BS 131 is located, the encryption key (and if necessary, session authentication information SAI4) for MS 407 must be sent from that HLR 109 to VLR 125 where MS 407 had re-addressed to complete the authentication process. Typically, at least a portion of the SAI is encrypted by the inter-key before transferring to another zone. If implicit authentication fails, then full authentication of MS 407 is performed.
A diagram showing the challenge and response process for authenticating a mobile station by an authentication center according to the TETRA standard is shown in FIG. 7. When authenticating an MS 707, an authentication center 701, such as a KMF 101, combines the mobile authentication key, K, with RS using the encryption algorithm TA11 as defined in the TETRA standard. The output The output of process TA11 703 is KS, which is entered with RAND1 (a random number) for the TA12 cipher algorithm as defined in the TETRA standard. From process TA12 705 comes out XRES1, an expected response, and DCK1, a derived cipher key for the mobile. RAND 1 and RS are provided for MS 707. MS 707 goes through a similar process by combining its mobile authentication key, K, with the RS received from AuC 701 using process TA11 703. From process TA11 703 KS is output, which is inserted with RAND 1 to process TA12 705. From process TA12 705, at MS 707, RES1, an answer
36 1 362 452 / EN to the challenge, and DCK1, the derived cipher key for the mobile. MS 707 sends RES1 to AuC 701. If XRES1 and RES1 match, AuC 701 sends an authentication pass message to MS 707, and communication about the newly created DCK1 air interface can begin. If the XRES and RES do not match, AuC 701 sends an authentication failure message to MS 707, and communication about the newly created DCK1 air interface is prohibited, although the previous DCK1 about the failed authentication may be used. authentication.
A diagram showing the challenge and response process for authenticating an authentication center by a TETRA mobile station is shown in FIG. 8. When authenticating an AuC 701, such as KMF 101, an MS 707 combines the mobile authentication key, K, with RS using the encryption algorithm TA21 as defined in the TETRA standard. From process TA21 801 aKS 'is output, which is entered with RAND2 (a random number) for the TA22 cipher algorithm as defined in the TETRA standard. From process TA22 803 comes XRES2, an expected response, and DCK2, a derived encryption key for mobile 707. RAND2 is supplied to AuC 701. AuC 701 goes through a similar process by combining the authentication key. K, for MS 707 with RS using process TA21 801. From process TA21 801 of AuC 701 exits aKS ', which is inserted with RAND2 to process TA22 803. The TA22 803 process output on AuC 701 is RES2, a challenge response, and DCK1, the derived cipher key for the rover. AuC 701 sends RES and RS to MS 707. If XRES and RES match, MS 707 sends an authentication pass message to AuC 701, and communication about the newly created DCK1 air interface can begin. If XRES and RES do not match, MS 707 sends an authentication failure message to AuC 701, and air interface communication with the newly created DCK1 is not performed.
A diagram showing the SAI distribution and authentication process between a communication system and a real time mobile station according to the invention is shown in FIG. 9. FIG. 9 shows an implementation of the TETRA standard authentication process including how various system devices within the infrastructure act.
36 1 362 452 / EN within the authentication process. FIG. 9 shows how ZC 107, including HLR 109 and VLR 111, and BS 115 acts as a delegation, or authentication agent, to KMF 101 in the authentication process. In non-real time, KS and KS 'encrypted by the key, and RS are passed together with KMF 101 to UCS 103, first ZM 105, and HLR 109 of first zone controller 107.
After BS 115 sends a request for MS 401 authentication to ZC 107, VLR 111 generates RAND1 and uses KS and RAND1 with process TA12 to generate XRES1 and DCK1 according to FIG. 7 included, and sends RAND1 and RS to BS 115, which sends RAND1 and RS over-air to MS 401. MS 401 combines its own K and RS with process TA11 to generate KS, then combines RAND1 and KS according to FIG. 7th included, developing RES1 and DCK1, and send RES1 to BS 115, which sends RES1 to VLR 111 in ZC 107. VLR 111 compares RES1 and XRES1, and the result is RI. When RES1 and XRES1 coincide, DCK1 and SAI for MS 401 are stored in VLR 111 and HLR 109 and DCK1 (encrypted by the interkey). In the preferred embodiment, DCK1 is keyed to the first zone before being sent to BS 115. The RI is sent to BS 115 in acknowledgment that the authentication has passed, and the BS 115 stores DCK1 and sends the RI to MS 401 indicating that the authentication has passed. When RES1 and XRES1 do not match, VLR 111 discards the newly created DCK1 without storing or sending to BS 115 and sends R1, a negative acceptance of the authentication process, to BS 115, and BS 115 sends Rl to MS 401 indicating that authentication failed.
To request infrastructure authentication, MS 403 sends RAND2 to BS 129, which sends RAND2 to VLR 125 on ZC 121. VLR 125 checks RS and KS 'and generates RES2 and DCK2 using process TA22 according to FIG. 8 is included, and sends RES2 and RS to BS 129, which sends RES2 and RS to MS 403 by air. MS 403 combines RS with its own K with process TA21, developing KS ' which is then combined with RAND2 in process TA22 according to FIG. 8th included, developing XRES2 and DCK2. MS 403 compares RES2 and XRES2. When RES2 and XRES2 match, MS 403 sends message R2 to BS 129 in acceptance that the
Authentication has passed, BS 129 sends R2 to ZC 121, and VLR 125 includes DCK2 and SAI to mobile 403 to be stored in VLR 125 and HLR to MS 403 and sends DCK2 to BS 129, which stores DCK2. In the preferred embodiment, DCK2 is keyed to the second zone before being sent to BS 129. When RES2 and XRES2 do not match, MS 403 sends message R2 to BS 129 indicating authentication failed, BS 129 sends R2 to ZC 121, and VLR 125 discards the newly created DCK2 without sending it to BS 129. .
In another authentication process, if VLR 111 in the zone where MS 401 or 403 is currently located does not have the SAI stored for MS 401 or 403, VLR 111 obtains the HLR SAI for MS 401 or 403. When HLR 109 for MS 401 or 403 is in the same zone, SAI is simply passed within ZC 107 to VLR 111. When the HLR 109 for MS 401 or 403 is in a different zone, the zone for the HLR home position is determined from a home position zone projection table that maps the ITSI to its home position zone, and the SAI is sent to ZC 107 to VLR 111. In the preferred embodiment, when key material is sent from HLR to MS 401 or 403 to VLR 111, at least something from SAI, in particular KS and KS ' , are encrypted with the interkey. When DCK is transferred within a zone, DCK is encrypted with KEK<sub>Z</sub>. Similarly, if the zone where authentication takes place is not the home position zone for MS 401 or 403, updated SAI and DCK information will be encrypted by the key at least in part and sent to the appropriate VLR. Because keys are passed between devices that request a different cipher key, one device receives a message, decrypts it with one key, and then encrypts the result with another key for the next device.
Mutual authentication when MS and infrastructure mutually authenticate each other is described with respect to FIG. 3 titled Mutual authentication initiated by SwMI and FIG. 4 entitled Mutual authentication initiated by MS and its associated TETRA texts. The resulting DCK (DCK1 and DCK2) from each process are combined using the cipher algorithm TB4, and the resulting DCK is used to
Communicate to MS 403 that you have sent an encrypted message, for example an updated encrypted location message. BS 115 may optionally send an encrypted message reception acceptance to mobile station 403. The identity, ITSI2, of MS 403 is CCK encrypted, and thus BS 115 is able to determine which MS has sent the message, even though it do not have DCK2 for MS 403. BS 115 requires ZC 107 DCK2. ZC 107 determines if it needs to require DCK2 from a different zone, which is required in this case, because MS2 403 is rerouted from a different zone, zone 2, and HLR 123 for MS 403 is in zone 2. ZC 107 determines which zone has the required key material and sends a request for that target zone to the key material. In the example, DCK2 is found in HLR 123 for zone 2, which is the target zone, and DCK2 is sent to ZC 107 from that zone HLR 123 after being encrypted with the KEK key.<sub>M</sub>. ZC 107 sends DCK2 to BS 115 encrypted with KEK key<sub>Z1</sub>. BS 115 uses DCK2 to decrypt the location update message for MS2 403, and any subsequent message (s) from MS 403, and send the location update to ZC 107. RS, KS, KS 'are requested. HLR 123 later so that full authentication can be performed when needed. In the preferred embodiment, the VLR 111 for MS 403 is not updated with the MS location until MS implicitly authenticates or performs full authentication. Receiving a properly deciphered location updated message is considered an implicit authentication, at which time the VLR 111 should be updated.
In the situation where it may be desired to pull a GCK / MGCK, the process is the same as described above in connection with DCK, except that VLR 111 obtains the GCK, combines it with a CCK, as described below in FIG. 15 and its associated text, and send the resulting MGCK, encrypted with the KEK key<sub>Z1</sub>for BS 115 or 117.
A diagram illustrating an input key within a communications system is shown in FIG. 11. The input key procedure is used to send a key, such as DCK or GCK / MGCK, to a sending site when an MS switches sites from its normal site to the site.
ΕΡ 1 362 452 / EN shipping. This process thus provides a mechanism for a key to be sent to a site prior to the arrival of MS 401 or 403, so that full encrypted hands-free routing can occur. FIG. 11 shows an example of a DCK2 transfer between zones and a DCK1 transfer within a zone. MS starts the procedure. Although KS, KS ', and DCK are stored encrypted in the HLR, and DCK are stored encrypted in the HLR and VLR in the preferred embodiment, they are shown unencrypted in FIG. 11 for the sake of simplicity.
MS 401 begins the routing process from BS1 115 having location area identification 1 (LAID1) at site 1 to BS2 117 having location location identification 2 (LAID2) at site 2 in zone 1 MS 401 sends BS1 115 a message indicating that MSI will route to site 2. In the preferred embodiment, this message is an OTAR staging message. BS 115 resets this message to ZC 107. ZC 107 determines whether or not the DCK needs to be transferred to another zone by determining whether or not the site to which the MS 401 is heading is in its zone or not. In this example, site 2 is also served by ZC 107, so there is no need to transfer the DCK to another zone. Because the DCK is transferred within the zone, ZC 107 responds to BS 115 with a short delay message. In this case, the BS 115 delays the MS 401 from switching to site 2 from a delay equivalent to the short delay, which delay approximates the time it takes to send the DCK to the next site from VLR 111 in the same zone. . In the preferred embodiment, the short delay is less than 50 ms. MS 401 waits for an ok from BS 115 before operating at the new site, for example, forwarding, switching sites, or communicating, and BS 115 sends the ok after the short delay period expires. During the delay period, the VLR 111 in ZC1 107 encrypts DCK1 with the intrakey and sends it to BS2 117 at site 2, where MS 401 and BS2 117 will be able to exchange encrypted messages using DCK1. In the preferred embodiment, the VLR 111 for M 401 is not updated with the MS location until MS 401 implicitly authenticates or performs full authentication.
36 1 362 452 / EN
MS2 403 begins the process of routing from BS3 129 having location area identification 3 (LAID3) at site 3 in zone 2 to BS1 115 having location location identification 1 (LAID1) at site 1 in zone 1. MS 403 sends a message to BS3 129 indicating that MS2 will route to site 1. In the preferred embodiment, this message is an OTAR Preparation message. BS 129 resets this message to ZC 121. ZC 121 determines whether or not the DCK needs to be transferred to another zone by determining whether or not the site to which the MS 401 is heading is in its zone or not. In this example, site 1 is not served by ZC 121, and thus there is a need to transfer the DCK to another zone. And because the DCK is transferred to another zone, ZC 121 responds to BS 129 with a long delay message of use. In this case, BS 129 delays MS 403 from switching to site 1 from a delay equivalent to the long delay, which delay approximates the time it takes to send VLR 111 DCK to the next zone site. In the preferred embodiment, a long delay is greater than or equal to 50 ms. MS 403 waits for an OK from BS 129 before switching sites, and BS 129 sends the ok after the long delay period has expired. During the delay period, the VR 125 on the ZC 121 encrypts DCK2 with the interkey and sends it to ZCl 107, which decrypts it with the interkey, encrypts it with the intrakey KEK<sub>Z1</sub>, and sends the result to BSl 115 at site 1, where MS 403 and BS2 115 will be able to exchange encrypted messages using DCK2. In the preferred embodiment, VLR 111 for MS 403 is not updated with the MS location until MS 403 implicitly authenticates or performs full authentication, at which point VLR 125 for MS2 on ZC2 121 is deleted. RS, KS, KS 'are requested some time later from the HLR on ZC3 223 (the HLR home position zone for MS 403) so that full authentication can be performed as required.
FIG. 12 is a diagram showing the distribution of a static cipher key to a BS within a communications system. SCK is a system wide voice traffic key that is used to encrypt voice, data, encrypted short identity (ESI), and signaling traffic when authentication is not available. SCKs are identified by SCKN and SCK-VN, and are stored in KMF 101 encrypted by
36 1 362 452 / EN a hardware switch and the TA31-encrypted ZM 105 and 119. In the preferred embodiment, there may be up to 32 different SCKs throughout the system. Each BS stores an SCK, identified by the SCK number (CKN), each of which has an SCK version number (SCK-VN), although the SCK may have multiple versions that are or have been used in the system. Each SCKN has an SCK-VN version number, and in the preferred embodiment both version numbers, that is, the two keys, are stored for each SCKN. MS should be able to store 32 SCK for one SCK-VN, and additionally for 32 SCK for another SCK-VN. The 31 additional SCKs in MS are set for direct operation between mobile stations. A new SCK replaces the older SCK-VN. SCK can be provided to BS and mobile stations in a number of ways, including via a variable key loader (KVL), through computer software such as available RSS software from Motorola, Inc., and through OTAR (repeat the key through the air) through the MS ATR home position zone. Although not shown in the drawing due to space constraints, SCKN and SCK-VN are shipped with SCK for identification purposes.
A process for transferring an SCK to each BS in the system is shown in FIG. 12. When KMF 101 determines that an SCK update is due, KMF 101 generates a new SCK. In order to determine the starting position zone of a BS, in the preferred embodiment, KMF 101 uses the BS to map the starting position of ZC from UCS 103 and a zone based lookup table to obtain the address for the ATR in the zone. KMF 101 encrypts SCK with KEK key<sub>Z</sub>, to the zone in which the BS is located, and sends the encrypted key to the ZM for that BS. ZM stores a copy and sends it to the planned BS. An unencrypted ACK is sent from BS to ZC and KMF 101 via ATR in the zone where BS is. The ACK represents that the SCK was received correctly at BS.
A specific example of an SCK transfer to BS1 115 includes a site information transfer, including a BS to map the home position zone controller, from UCS 103 to KMF 101. KMF 101 uses projection to determine BS1 115 is located in the
Zone 1. KMF 101 generates the SCK and encrypts it with the KEK key.<sub>Z1</sub>, for zone 1 where BSl is located. KMF sends the encrypted SCK to ZM 105 for zone 1. ZMl 105 stores a copy of the encrypted SCK and sends it to BSl 115 over a line connection. BSl 115 decrypts encrypted SCK using KEK<sub>Z1</sub> and stores the unencrypted SCK. When SCK is correctly received by BS1, BS1 115 sends an unencrypted ACK to KMF 101 via ZC1 107 and ATR 113 in zone 1. SCK transfers to BS3 and BS4 are performed similarly.
A diagram showing the distribution of a static encryption key to a mobile station within a communications system is shown in FIG. 13. When KMF 101 determines that an SCK upgrade is due for an MS 401, KMF 101 generates a new SCK key material for MS 401 according to FIG. 10 entitled Distribution of SCK to an individual by an authentication center and its associated text in the TETRA standard. The SCK generation process develops SSCK key material (a sealed SCK), SCKN (SCK number), SCK-VN (SCK version number), and RSO (random source used in the process). In order to determine the MSR1 home position zone ATR, in the preferred embodiment, KMF 101 uses ITSI to map the ZC home position from UCS 103 and a zone-based lookup table to obtain the address. from the ATR to the home position zone. In the example of FIG. 13, the home position zone for MSI 401 is zone 2. KMF 101 sends SSCK, SCKN, SCK-VN, and RSO to ATR 127 from home position zone (2) for MS 401. If MS 401 is not in the system, ATR 127 sends a NACK back to KMF 101. If MS 401 is in the system, SCK is delivered to MS 401 through the zone in which MS 401 is normally located. In the preferred embodiment, the SCK key material (e.g. SSCK, SCKN, SCK-VN, and RSO) is not encrypted for transfer between system devices. SCK key material may optionally be encrypted for transfer between system devices.
When the MS 401 is not located in its home position zone, zone 2 home position controller 121 determines which zone the MS 401 is in.
Normally located (zone 1 in FIG. 12) when looking at zone 2 HLR 123. ZC2 121 sends the SSCK, SCKN, SCK-VN, and RSO to zone controller 107 of the zone where MS 401 is currently located. ZC1 107 sends SSCK, SCKN, SCK-VN, and RSO to BS 115 where MS 401 is located. The BS 115 decrypts the SSCK, SCK-VN and RSO with the KEK key.<sub>Z1</sub>, and sends the result to MS 401. An unencrypted ACK is sent from MS 401 to BS 115 to ZC 107 and KMF 101 via ATR 113 in the zone where BS resides. The ACK represents that the SCK was received and properly deselected in MS (the sealing process is described in the TETRA standard).
When MS 401 is located in its home position zone (not shown, but assumed to be in BS3 129 because of this example), home position zone controller VLR 121 sends SSCK, SCKN, SCK-VN, and RSO to BS 129 where MS 401 is located (not shown but assumed for this example). BS 129 sends SSCK, SCKN, SCK-VN, and RSO to MS 401. An unencrypted ACK is sent from MS 401 to BS 129 to ZC 121 and KMF 101 via ATR 127 in the area where BS 115 resides. The ACK represents that the SCK was received and correctly deselected in MS (the sealing process is described in the TETRA standard).
FIG. 14 is a diagram showing the distribution of a common cipher key to a mobile station and a BS within a communications system. CCK is a location-based traffic key that is used to encrypt voice, data, and signaling within a location area (LA) and is only used for outside connected communications. The CCK is intended for use with the TETRA group call traffic cipher. CCK is also used to encrypt the subscriber identity by creating the encrypted short identity (ESI). Group call traffic within LA uses CCK when no GCK is available or turned off. There is one CCK per location area. A location area can be as small as a site, and so can be as many CCK as sites in the system. It is possible for more than one location area to have the same CCK. The CCK is identified by the CCK-ID (for example, CCK1, CCK2, and so on) and by the location area identification (LAID). Two copies of each CCK (the last two CCKΕΡ 1 362 452 / EN
ID) are in the ZC and BS to provide a gradual key repetition of the MS in the system. While one CCK is in use, the following is distributed to MS. In the preferred embodiment, each site maintains a CCK for each site contiguous to the one-site full-time hands-free site and to facilitate administration of consistent mobility. When a contiguous CCK is given to an MS, the last two CCKs are transferred to the MS. A new CCK replaces the older CCK-ID. CCK long term storage takes place in ZM 105 and 119. The TETRA standard supports various processes for supplying CCK over the air, and the same order / supply methodology used for each of the air interface switches, and also allows the key request with cell registration and change by a mobile station.
The CCK procedure for BS illustrated in FIG. 14 is used to transfer a CCK from KMF 101 to a BS (site) 115. KMF 101 determines that it is time for the CCK of a BS 115 to be updated and generates the appropriate CCK (s). In the preferred embodiment, each BS is a Location Area (LA) and has its own Location Area Identification (LAID). FIG. 14 shows the transfer of CCK1 and CCK2 to zone 1 and the transfer of CCK3 to zone 2. CCKs are encrypted with the KEK key<sub>Z1</sub>, for the area where LA is located. UCS 103 provides a zone-to-zone projection and a zone ZM projection for KMF 101. KMF 101 uses these projections to send keys directly to the appropriate ZM 105 or 119, which stores the CCK and sends the CCK. to zone controller 107 or 121. UCS 103 takes the site parameters from ZM 105 and 119 to create the contiguous site list that is sent to KMF 101 and send ZM 105 and 119 to be sent to zone controllers 107 and 121 for use. If a contiguous site is in a different zone, the key is transferred between the involved ZCs. ZC Encrypt CCK with KEK Key<sub>m</sub>, to transfer between zone controllers. Using the contiguous site list, zone controllers 107 and 121 send the contiguous site CCK to the appropriate sites. Thus, each site in the contiguous site list will have CCKs for sites contiguous to that site. Contiguous CCKs are used so that MS can request CCK for the contiguous site before MS switches the sites. BS 115 can
Also send CCKs to MS as new CCKs are received at S 115. CCKs are DCK-encrypted for special MS 401 before transmission of encrypted CCK to MS 401. ACKs are sent by BS to ZC and are returned to KMF 101 via ATR (where BS resides). Because KMF 101 is unaware of contiguity, it does not need the ACKs of contiguous CCK distributions. Because KMF 101 follows which BS is given a CCK, BS follows the general acceptance of CCK, that is, which MS has a CCK for a given Location Area, and sends ACK since the CCK is normal.
Because MGCK is a combination of CCK and GCK, the zone controller will create four MGCKs using the last two CCK-ID and the last two GCK-VN and distribute them accordingly.
CCK is a zone-specific parameter and thus there is no need to go through UCS 103. Thus KMF 101 sends CCK information directly to the appropriate zone administrator 105 or 119 which is different than the methodology of repeat the key of other air interface keys. UCS 103 obtains site information from zone administrators 105 or 119 to create the contiguous site list. When placing CCKs in contiguous sites, real-time CCK processing is reduced, ie BS does not need to query the CCK zone controller for a contiguous BS when an MS requests a CCK to a neighboring site, and so MS does not need to process a CCK when MS switches sites.
FIG. 15 is a diagram showing the distribution of a group cipher key to a BS within a communications system. GCK is identified by GTSI (TETRA Group Subscriber ID as referred to in the TETRA Standard) and GCK-VN. In the preferred embodiment, GCKN is logically equivalent to GTSI from a key management perspective. Long term storage of GCK occurs at UCS and ZM. MGCK, which is a combination of GCK and CCK, is identified by GTSI (or GCKN), CCK-ID (with LAID), and GCK-VN. Four MGCK per speech group (GTSI) are identified by the last two CCK-ID and the last two GCK-VN. MGCKs are not stored in a ZC 107 or 11, but they are created by a ZC 107 or 121 and
1 362 452 / EN sent to BS 115 provided that an MS associated with that GTSI is at the site of BS 115 which does not receive the GCK because it is a long term key. Although not shown in the drawing due to space constraints, GCK-VN is shipped together with GCK and MGCK for identification purposes.
The procedure for upgrading a GCK to a speech group recording has two parts. The first part includes the update of the GCK present in the speech group, the second part includes the generation of the resulting MGCK as a result of the update and distribution of the MGCK to the sites.
procedure of FIG. 15 transfers a GCK from KMF 101 to the HLR speech group on the zone controller in the home position zone to the speech group. When KMF 101 determines that it is time for the GCK to be updated, KMF 101 generates a GCK for each speech group and maintains a GTSI-GCK table. GCKs are stored encrypted from hardware in KMF 101. KMF 101 does not know which ZC has the HLR for GTSI, so KMF 101 sends the GCK encrypted with the KEK key.<sub>M</sub>, for UCS 103. UCS 103 stores the key material and sends it to the home position ZM 10 or 119 for the GCK-associated speech group (GTSI). The ZM 105 or 119 sends the key material to its ZC 107 or 121 which stores the key material in the HLR group to KEK encrypted GTSI<sub>M</sub>. ZC 107 verifies that the key material can be deciphered correctly and sends an ACK back to KMF 101 via ATR 113 where the HLR 109 group for GTSI resides. The ACK reflects that HLR 109 contains a correct encrypted copy of GCK. ZC 107 decrypts key material with KEK<sub>M</sub>, and re-encrypt the same with the key KEK<sub>Z</sub>, for storage in VLR 111. Any other VLRs, such as VLR2 125, outside the GTSI associated home position zone, will have the GCK encrypted with KEK<sub>M</sub> sent to them. FIG. 15 shows both cases of interzone and intraszone.
Because MGCK is a combination of GCK and CCK generated by a ZC using the TA71 algorithm 1501, 1503, or 1505, when GCK changes or CCK changes, MGCK must also change in the same way. The four MGCKs are sent to all sites with a group membership.
ΕΡ 1 362 452 / EN speech combining GTSI to GCK. Because the last 2 CCK-ID and the last 2 GCK-VN are stored, four versions of MGCK need to be sent to BS.
As in other cases, when sending MGCK to a site, it needs to be encrypted using the KEK key.<sub>Z</sub>. GCK is obtained from VLR speech group recording and decrypted with the KEK key.<sub>Z</sub>, and combined with CCK to create MGCK. The resulting MGCK is encrypted using the KEK key.<sub>Z</sub>, and sent to the appropriate sites.
The transfer from an MGCK to a BS can be triggered by a number of events. Examples of triggers include a GCK-associated mobile station for MGCK residing in BS when either GCK or CCK is generated; a mobile station arriving at BS when no previous speech group membership in BS has occurred; and a mobile station changing the speech group membership while residing in BS to a speech group not previously associated with BS.
A diagram showing the distribution of a group cipher key to a mobile station within a communications system is shown in FIG. 16. When KMF determines that a GCK upgrade is due for an MS 401, KMF 101 generates a new GCK key material for MS 401 according to FIG. 8 titled Distribution of a group cipher key to an individual and their associated text in the TETRA standard. The GCK generation process develops SGCK key material (a sealed GCK), GCKN (GCK Number), GCK-VN (GCK Version Number), and RSO (the random source used in the process). In order to determine the ATR for the MS 401 home position zone, in the preferred embodiment, KMF 101 uses ITSI to map the home position ZC from UCS 103 and a zone based lookup table to obtain the address. from the ATR to the home position zone. In the example of FIG. 16, the starting position zone for MS 401 is zone 2. KMF 101 sends SGCK, GCKN, GCK-VN, and RSO to ATR 127 from starting position zone (2) to MS 401. If MS 401 is not in the system, ATR 127 sends a NACK back to KMF 101. If MS 401 is in the system, GCK is delivered to MS 401 through the zone in which MS 401 is normally located. In the preferred embodiment, the
36 1 362 452 / EN CK key material (for example, SGCK, GCKN, GCK-VN, and RSO) is not encrypted for transfer between system devices. GCK key material may optionally be encrypted for transfer between system devices.
When MS 401 is not located in its home position zone, zone 2 home position controller 121 determines which zone where MS 401 is normally located (zone 1 in FIG. 16) when viewing in HLR 123 of zone 2. ZC2 121 sends SGCK, GCKN, GCK-VN, and RSO to zone controller 107 of the zone where MS 401 is currently located. ZC1 107 sends SGCK, GCKN, GCKVN, and RSO to BS 115 where MS 401 is located. BS 115 sends SGCK, GCKN, GCK-VN, and RSO to MS 401. An unencrypted ACK is sent from MS 401 to BS 115 to ZC 107 and KMF 101 via ATR 113 in the zone where the BS 115 resides. The ACK represents that the GCK was received and properly deselected in MS (the sealing process is described in the TETRA standard).
When MS 401 is located in its home position zone (not shown, but assumed to be in BS3 129 because of this example), home position controller 121 sends SGCK, GCKN, GCK-VN, and RSO to the BS 129 where MS 401 is located (not shown but assumed for this example). BS 129 sends SGCK, GCKN, GCK-V, and RSO to MS 401. An unencrypted ACK is sent from MS 401 to BS 129 to ZC 121 and KMF 101 via ATR 127 in the zone where the BS 115 resides. The ACK represents that the GCK was received and properly deselected in MS (the sealing process is described in the TETRA standard).
FIG. 17 is a flowchart showing a key retention process at a site in a communication system according to the invention. Key permanence refers to how long a key remains stored on any system device or MS. If an air interface traffic key is deleted and a site when MS leaves the site, and the key is removed very quickly, MS can return to the site requiring the key to be adjusted again. If MS is traveling across zone boundaries or site boundaries for a period of time, the key material for MS
36 1,362 452 / EN may need to be constantly adjusted if key material is deleted from a site very quickly after MS leaves the site. If key material is left in one place for a long time, duplicate keys can be adjusted, creating ambiguity and similarity of authentication failures, particularly for implicit authentication. Thus, the key permanence for each key needs to be adjusted accordingly to avoid such problems. In the preferred embodiment, the dwell time is based on an expected average authentication ratio in the communication system, and preferably the dwell time is less than the expected average authentication ratio in the communication system. The expected average authentication ratio is based on an average number of times a mobile station authenticates within a period of time.
At step 1701, when the MS arrives at a site, the key (s) and / or key material associated with the MS 401 are stored at the site. If at step 1703 it is determined that the mobile has left the site, a dwell timer is set at step 1705 unless it has already been set or set to zero, in which case the process simply continues with step 1709. When the timer expires at step 1707, the process continues with step 1709 where the key (s) and / or key material associated with mobile 401 are deleted from the site, and the process is terminated. If cabinet 401 did not leave the site at step 1703, and it is time to replace the cabinet key (s) and / or key material at step 1711, the key (s) and / or key material is replaced at step 1713 and the process continues with step 1703. Step 1709 may also be reached (not shown) if a system device such as a zone controller directs the site to erase certain key (s) and / or key material for any reason. The zone controller typically determines when the mobile leaves a site supported by HLR and VLR updates.
The present invention may be encompassed in other specific forms without departing from its essential characteristics. The embodiments described are to be considered in all respects as illustrative only and not restrictive. The scope of the invention is therefore indicated by the claims
36 1 362 452 / EN only more than by the preceding description. All changes that come within the meaning and equivalence range of the claims are to be adopted within their scope.
Lisbon,
36 1 362 452 / EN
Contents13
13 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13
28 members in 9 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 78572201 | United States of America | A | |
| 78572201 | United States of America | A | |
| 785722 | – | – | – |
| US20010785722 | – | – | – |
Members28
| Document | Office | Kind | |
|---|---|---|---|
| WO02067495A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2002154776A1 | United States of America | A1 | |
| WO02067495A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1362452A2 | European Patent Office (EPO) | A2 | |
| IL157048D0 | Israel | D0 | |
| EP1362452A4 | European Patent Office (EPO) | A4 | |
| US7123719B2 | United States of America | B2 | |
| EP1362452B1 | European Patent Office (EPO) | B1 | |
| AT345621T | Austria | T | |
| DE60216050D1 | Germany | D1 | |
| EP1742411A1 | European Patent Office (EPO) | A1 | |
| EP1744484A1 | European Patent Office (EPO) | A1 | |
| PT1362452EThis record | Portugal | E | |
| DK1362452T3 | Denmark | T3 | |
| US2007098171A1 | United States of America | A1 | |
| US2007101141A1 | United States of America | A1 | |
| DE60216050T2 | Germany | T2 | |
| ES2274964T3 | Spain | T3 | |
| US7424116B2 | United States of America | B2 | |
| US7522727B2 | United States of America | B2 | |
| IL157048A | Israel | A | |
| EP1742411B1 | European Patent Office (EPO) | B1 | |
| AT501560T | Austria | T | |
| DE60239429D1 | Germany | D1 | |
| ES2360943T3 | Spain | T3 | |
| EP1742411B8 | European Patent Office (EPO) | B8 | |
| EP1744484B1 | European Patent Office (EPO) | B1 | |
| AT552668T | Austria | T |
Numbers
- Publication, DOCDB
- 1362452
- Publication, EPODOC
- PT1362452E
- Application
- 2717354
- Application, DOCDB
- 02717354
- Application, EPODOC
- PT20020717354T
Titles2
- English
- METHOD AND APPARATUS FOR PROVIDING AUTHENTICATION IN A COMMUNICATION SYSTEM
- Portuguese
- PROCESSO E APARELHO PARA FORNECER UMA AUTENTICAÇÃO NUM SISTEMA DE COMUNICAÇÕES
Classification
- CPC, 19
- H04W12/04
- H04L9/0822
- H04L9/0833
- H04L9/0869
- H04L9/0891
- H04L9/3273
- H04L63/061
- H04L2209/80
- H04L2463/062
- H04W12/0401
- H04W88/04
- H04W12/06
- H04W12/04031
- H04W12/0433
- H04W12/04033
- H04W12/0431
- H04W12/0609
- H04W12/041
- H04W12/069
- IPC, 3
- H04L9 32
- H04W12 06
- H04W88 04