WO2012021284A2 - Procédés adaptés pour établir une session sécurisée dans un système de communication - Google Patents

Procédés adaptés pour établir une session sécurisée dans un système de communication Download PDF

Info

Publication number
WO2012021284A2
WO2012021284A2 PCT/US2011/045196 US2011045196W WO2012021284A2 WO 2012021284 A2 WO2012021284 A2 WO 2012021284A2 US 2011045196 W US2011045196 W US 2011045196W WO 2012021284 A2 WO2012021284 A2 WO 2012021284A2
Authority
WO
WIPO (PCT)
Prior art keywords
message
security
initiating device
timestamp
security gateway
Prior art date
Application number
PCT/US2011/045196
Other languages
English (en)
Other versions
WO2012021284A4 (fr
WO2012021284A3 (fr
Inventor
Thomas J. Senese
Chris A. Kruegel
Timothy M. Langham
Todd A. Leigh
Timothy G. Woodward
Original Assignee
Motorola Solutions, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/174,324 external-priority patent/US20120036567A1/en
Application filed by Motorola Solutions, Inc. filed Critical Motorola Solutions, Inc.
Priority to CA2807499A priority Critical patent/CA2807499C/fr
Priority to AU2011289780A priority patent/AU2011289780A1/en
Publication of WO2012021284A2 publication Critical patent/WO2012021284A2/fr
Publication of WO2012021284A3 publication Critical patent/WO2012021284A3/fr
Publication of WO2012021284A4 publication Critical patent/WO2012021284A4/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Definitions

  • the technical field relates generally to secure session establishment or, more particularly, to methods for authenticated time synchronization and for network access control for communication devices using dynamically assigned Internet Protocol (IP) addresses.
  • IP Internet Protocol
  • the information may travel through a network such as the Internet.
  • the devices may implement one or more core security services, such as confidentiality, authentication, etc., wherein confidentiality (e.g., the use of encryption/decryption algorithms) provides information privacy and is applied to the information so that it is understandable only by the intended recipient, and authentication is a process that evaluates the genuineness of the originator and recipient of the information.
  • confidentiality e.g., the use of encryption/decryption algorithms
  • authentication is a process that evaluates the genuineness of the originator and recipient of the information.
  • IPsec Internet Protocol Security
  • security session establishment protocols such as the Internet Key Exchange (IKE) defined in RFCs 2409 (IKEvl) and 4306 (IKEv2) are used to provide security session access control and exchange of data relevant to the security session, such as a basis for replay protection.
  • IKE Internet Key Exchange
  • IKEvl Internet Key Exchange
  • IKEv2 Internet Key Exchange
  • IKEv2 Internet Key Exchange
  • IKEv2 Internet Key Exchange
  • IKEv2 Internet Key Exchange
  • IKE is widely used in peer-to-peer networks, often when the network connecting the two peers is a high bandwidth network. In this case, the overhead associated with the several messages transferred as part of an IKE session
  • FIG. 1 is a system diagram of a communication system implementing embodiments of the present disclosure.
  • FIG. 2 is a message sequence chart illustrating a method for security session establishment in accordance with an embodiment.
  • FIG. 3 is a message sequence chart illustrating a method for security session establishment in accordance with another embodiment.
  • FIG. 4 is a table illustrating a format of a timestamp provided in the message exchange of the message sequence charts shown in FIG. 2 and FIG. 3.
  • FIG. 5 illustrates a format of a header used in the messages exchanged in the message sequence charts shown in FIG. 2 and FIG. 3.
  • a security gateway and an initiating device perform methods for establishing a security session.
  • the methods includes the security gateway: receiving a first message from an initiating device, the first message including a first message authentication code; validating the first message using the message authentication code; and responsive to the validating, sending a second message to the initiating device, the second message including a timestamp and further including a second message authentication code for authenticating of the timestamp by the initiating device, wherein the first and second messages are used to establish the security session, and the authenticated timestamp is used for subsequent replay protection of messages between the security gateway and the initiating device.
  • the method further includes the security gateway validating a dynamically assigned IP address for the initiating device to use in authorizing access of the initiating device to the security gateway.
  • the security session establishment procedure in accordance with the present teachings at a minimum, mutually authenticates both endpoint devices, provides an authorization mechanism for an initiating device to access a security gateway, and synchronizes an authenticated basis for replay protection, while using fewer and much smaller bandwidth messages than when using the IKE protocol.
  • system 100 may be a Project 25 compliant system (i.e., the system elements perform protocols as defined in Project 25 standards documents), or a TETRA compliant system, or another type low bandwidth system, where it is disadvantageous to use the IKE protocol for security session establishment.
  • System 100 includes a Host 102 (such as a data application server in an enterprise network) and a host communication device 106 (illustrated as a radio but which can be any communication device that includes one or more applications and includes a security processing function), wherein each "host” may have running thereon applications that require secure communications.
  • Host 102 such as a data application server in an enterprise network
  • host communication device 106 illustrated as a radio but which can be any communication device that includes one or more applications and includes a security processing function
  • system 100 further includes a data encryption gateway (DEG) 104 and a DEG function (not shown) physically integrated within the radio 106 that communicate using a network 108, which in this case is an IP network (wherein IPv4 or IPv6 is implemented to enable endpoints to be reachable anywhere within system 100 using IP addresses). Accordingly, security processing by the DEGs is implemented in system 100 using IPsec.
  • network 108 can be any type of suitable network, wherein security processing is performed using a correspondingly suitable security processing protocol.
  • system 100 includes an infrastructure device 110 (such as a base site, base station, or the like) through which the radio 106 attaches to and
  • DEG 100 is shown as having two Host devices 102 and 106 and only two DEGs (only DEG 104 shown) for ease of illustration. However, in an actual system implementation, there may be hundreds and even thousands of host devices that use system 100 to facilitate communications with other host and infrastructure devices in system 100. Moreover, there may be additional DEGs in an actual system implementation, including DEGs that serve a number of host devices such as DEG 104.
  • DEG 104 in this illustrative implementation, provides data application services for multiple communication devices such as radio 106.
  • radio 106 In order for the radio 106 to access the data application services within host 102, radio 106 needs to authenticate to the DEG 104, which serves as a security gateway to a Virtual Private Network (VPN) that includes the host 102, wherein the DEG further serves to authorize VPN traffic, which is defined as traffic or messages communicated between the security gateway (e.g., DEG) and authenticated communication devices.
  • the authorized VPN traffic also undergoes security processing by the DEGs, using a data security protocol (which in this case is IPsec), as it travels through the network 108 to provide secure communications between the hosts 102 and 106.
  • a data security protocol which in this case is IPsec
  • security processed messages Messages that have undergone security processing using a data security protocol are termed, herein, as "security processed messages.” Accordingly, messages that have undergone IPsec processing are deemed security processed IPsec messages. As the term is used herein, a message is defined as a unit of
  • a security session is established between the DEG 104 and the DEG in the radio 106.
  • a "security session” is established between the DEG 104 and the DEG in the radio 106.
  • a security session is defined as the result of applying a security session establishment procedure; the security session and security processing of messages provide a secure "tunnel" 112 for messages traveling through the network 108.
  • IKE served as the security session establishment procedure.
  • IKE is not suitable for low bandwidth systems. Therefore, the present disclosure provides an alternative security session establishment procedure used to establish a security session using fewer and smaller messages than IKE. Examples of the security session establishment procedure in accordance with the present teachings are described by reference to Figures 2-5.
  • the data application function and security processing function can be housed within separate physical devices (e.g., Host 102 and DEG 104) or physically integrated within the same physical device (e.g., radio 106).
  • the security processing can be integrated into the single device using an integrated architecture implementation, wherein the security processing is natively in the layer-3 IP layer such as with IPv6; or using a bump in the stack (BITS) architecture that creates a protocol layer, e.g., an IPsec layer, that sits between the layer-3 IP layer and the layer-2 data link layer. The new layer intercepts packets sent down from the IP layer and adds security to them.
  • a bump in the wire a bump in the wire (BITW)
  • architecture is realized by a separate device that is placed within strategic points in the network to provide core security services to, for example, entire network segments.
  • the Hosts 102 and 106 and the DEGs are each implemented using (although not shown) a memory, one or more network interfaces, and a processing device that are operatively coupled, and which when programmed form the means for these system elements to implement their desired functionality, for example as illustrated by reference to the MSCs shown in FIG. 2 and FIG. 3.
  • the network interfaces are used for passing signaling, also referred to herein as messaging, (e.g., messages, packets, datagrams, frames, superframes, and the like) between the elements of the system 100.
  • signaling also referred to herein as messaging, (e.g., messages, packets, datagrams, frames, superframes, and the like) between the elements of the system 100.
  • the implementation of the network interface in any particular element depends on the particular type of network, i.e., wired and/or wireless, to which the element is connected.
  • the interfaces may comprise a serial port interface (e.g., compliant to the RS-232 standard), a parallel port interface, an Ethernet interface, a USB interface, and/or a Fire Wire interface, and the like.
  • a serial port interface e.g., compliant to the RS-232 standard
  • a parallel port interface e.g., an Ethernet interface, a USB interface, and/or a Fire Wire interface, and the like.
  • the interfaces comprise elements including processing, modulating, and transceiver elements that are operable in accordance with any one or more standard or proprietary wireless interfaces, wherein some of the functionality of the processing, modulating, and transceiver elements may be performed by means of the processing device through programmed logic such as software applications or firmware stored on the memory device of the system element or through hardware.
  • the processing device utilized by these elements may be partially
  • the memory implemented by these system elements can include short-term and/or long-term storage of various information needed for the functioning of the respective elements.
  • the memory may further store software or firmware for programming the processing device with the logic or code needed to perform its functionality.
  • FIG. 2 shown therein is a security session establishment procedure, in accordance with an embodiment of the present disclosure, comprising a sequence of messages 206 and 208 of a message sequence chart (MSC) 200.
  • MSC message sequence chart
  • message 206 and 208 are exchanged between a radio 202 (the initiating device, which normally sends the initial message that starts the security session establishment procedure) and a DEG 204 (the security gateway).
  • message 206 is an IPsec Session Initiation Request
  • message 208 is an IPsec Session Initiation Response.
  • Message 206 comprises a header (HDR), an identifier for radio 202 (Radio ID), a nonce (Ni), and a parameter AUTH.
  • Message 208 comprises a header (HDR), a timestamp (TIME), a nonce (Nr), and a parameter AUTH.
  • TIME timestamp
  • Nr nonce
  • parameter AUTH a parameter AUTH
  • AUTH is a Message Authentication Code (MAC), e.g., an 8-byte MAC.
  • MAC Message Authentication Code
  • a MAC algorithm sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an arbitrary- length message to be authenticated, and outputs a MAC (sometimes known as a tag).
  • the MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.
  • AUTH function ⁇ HDR, TIME, Nr, Ni, auth_key ⁇ .
  • the secret key (auth_key) can be provisioned in both the radio 202 and DEG 204 using over the air rekeying (OTAR) or Key Fill.
  • the same or a different secret key may also be provisioned in both devices using OTAR and used for encrypting the messages 206 and 208.
  • HDR, TIME, Nr, and Ni are next described.
  • FIG. 3 have the format of an IKE header, and more particularly, an IKEv2 header.
  • FIG. 5 shows an example IKE header 500 with fields 502, 504, 506, 508, 510.
  • Table 1 defines the fields contained in message 500:
  • the SPI security parameter index
  • Initiator' s/Responder ' s defined, for instance, as a concatenation of algorithm ID SPI (502 and 504) (ALGID), key ID (KID), and manufacturer's ID (MFID) fields.
  • AGID algorithm ID SPI
  • KID key ID
  • MFID manufacturer's ID
  • This SPI is similarly constructed based on a key used to protect session establishment messages. This is an extension of RFC 4306.
  • P25 AUTH exchange for indicating the message exchange in accordance with the present teachings. This is an extension of RFC 4306.
  • Flags (506) I (initiator) and R (responder) flags are used as defined below. This is an extension of RFC 4306.
  • Length Same use as defined in RFC 4306, wherein it indicates a length of total message (header + payloads) in octets.
  • Nonce is a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.
  • random or pseudo-random means non-order or non-coherence in a sequence of symbols or steps, such that there is no intelligible pattern or combination, and such numbers can be generated using any suitable random (or pseudo-random) number generator function.
  • Ni signifies the nonce sent by the initiating device
  • Nr signifies the nonce sent by the responder, e.g., the security gateway.
  • a replay attack is defined as a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.
  • a technique that protects against or guards against a replay attack is deemed to provide "replay protection".
  • replay protection is provided for in the prior art using sequence numbers that are initiated using IKE.
  • the present disclosure provides for a novel replay protection technique for use with IPsec, as further described below.
  • TIME is a timestamp, which is defined as a sequence of characters denoting the date and/or time at which a certain event occurred, such as a recorded time at which a message was sent.
  • TIME is a 32-bit value.
  • An illustrative timestamp format with 32 bits is contained in a table shown in FIG. 4, wherein a first column 402 indicates a timestamp sub-field, and a second column 404 indicates a length of the corresponding sub-field. As illustrated, the timestamp includes the following sub-fields: Month (4 bits), Day (5 bits), Hour (5 bits), Minute (6 bits), Microslot (2 bits).
  • the radio initiates the handshake (message sequence).
  • the first message (206) is authenticated or validated with a MAC, where the initiator's nonce (Ni) is used to add freshness to the message digest.
  • the security gateway 204 responds to message 206 by sending, in the message 208, its current time (TIME), thereby, providing a timestamp that has the format shown in FIG. 4, for example.
  • TIME current time
  • the radio 202 unit verifies that the responder is not sending a replayed message by validating the MAC, whose message digest uses the original initiator's nonce.
  • the security gateway sends a rejection notification to the radio in place of the second message 208 that is shown in FIG. 2.
  • the AUTH function for generating the MAC uses both Ni and Nr. Nr is sent in message 208 and Ni is "implied" in that the radio 202 should know its nonce.
  • the radio 202 uses the implied Ni, as well as the explicit Nr, to calculate the AUTH value, and then compares the calculated AUTH value to the AUTH value that it received in message 208; although, in an alternative
  • Ni could also be sent in message 208 (and 308 of FIG. 3).
  • the radio 202 does not transact with the security gateway 204 if it fails to complete AUTH validation process. However, upon completing the AUTH validation process using the MAC, the timestamp provided by the gateway device 204 is authenticated.
  • FIG. 2 illustrated a two-message sequence for completing the establishment of a security session between a radio and a security gateway device in accordance with the present teachings.
  • FIG. 3 illustrates a three-message sequence for completing the establishment of a security session between a radio and a security gateway device in accordance with the present teachings.
  • a MSC 300 includes messages 306, 308, and 310 exchanged between a radio 302 (the initiating device) and a DEG 304 (the responding device and security gateway). Messages 306 and 308 are the same are messages 206 and 208 of FIG. 2, and the description of these messages is not repeated here for the sake of brevity.
  • MSC 300 includes the third message 310 as a means of further strengthening the security session establishment process by providing another opportunity for reply protection of the message.
  • message 310 includes a HDR, Nr, and AUTH, wherein the Nr is the same Nr provided in message 308, which serves as replay protection and enables the DEG 304 to validate message 310 by validating the AUTH value (MAC).
  • Nr is the same Nr provided in message 308, which serves as replay protection and enables the DEG 304 to validate message 310 by validating the AUTH value (MAC).
  • the authenticated timestamp is used in providing replay protection. More particularly, the authenticated timestamp is used for replay protection of security processed messages sent between the radio and DEG after the security session is established.
  • the session establishment synchronizes authentic time between the radio and the security gateway. The time is used to construct a number that can only be used once. The purpose of this number is to provide uniqueness to a message that is being authenticated through the MAC, and thus prevent replay of the message.
  • Both security endpoints need to have the synchronized timestamp in order to implement the time-based authentication validation.
  • the authenticated timestamp is used for replay protection of IPsec security processed messages sent between the radio and DEG after the security session is established. More particularly, with regards to replay protection, the radio needs to keep its time synchronized with the time of the security gateway. This can be done initially through the session-establishment exchange, where the timestamp is authenticated by the MAC. The radio can also readjust its authenticated time to account for drift by checking the unauthenticated time using any suitable means such as on a trunking control channel or by checking time broadcasts on a conventional traffic channel.
  • the radio If the radio sees the broadcasted control channel time change abruptly, and determines that the unauthenticated control channel time differs significantly (e.g., is outside of a defined threshold) with the authenticated timestamp that was initialized by the security gateway, then the radio does not resynchronize its authenticated time to the new control channel time.
  • the radio instead requests to receive an authenticated time stamp from the security gateway by initiating a new session-establishment exchange.
  • the radio only reinitiates the session-establishment exchange when it either receives or needs to transmit a new security processed message that includes or needs to have included therein an authenticated time stamp.
  • the radio or security gateway inserts, into a security processed message (such as an IPsec message), a current timestamp that is derived from the authenticated timestamp; or in other words, the current timestamp uses the authenticated timestamp as a security processed message (such as an IPsec message).
  • a security processed message such as an IPsec message
  • the current timestamp is inserted into a sequence number field of an Encapsulating Security Payload (ESP) header or into a sequence number field of an Authentication Header (AH) protocol header within the IPsec message. Furthermore, the current timestamp may be inserted into an unencrypted portion of a payload in the IPsec message.
  • the radio or the security gateway receives an IPsec having a timestamp included in a sequence number field of an ESP or AH header of the IPsec message; and verifies the timestamp in the sequence number field against the authenticated timestamp to evaluate the IPsec message for replay attack.
  • the ESP header's Sequence Number field is 32 bits in length, and is populated with the ESP transmitter's current time stamp.
  • the subfields that are inserted into the Sequence Number field include: Month, Day, Hour, Minute, and Microslot (12 bits), as shown in FIG. 4.
  • Using 12 bits for the Microslot field provides time granularity of 15 Ms.
  • a crypto period on the security equipment may be changed at least once per year in order to prevent roll-over of the time stamp.
  • the current time can also be inserted into the unencrypted portion of the payload.
  • the receiving ESP device compares the timestamp in the received ESP packet to its own current time as part of the procedure to qualify (verify) the packet. A packet that is deemed to be too old, or one with a time stamp that has previously been sent from the same source, is discarded.
  • An advantage of using time instead of sequence number is that time can be used to prevent replay of group messaging.
  • An ESP device should also be capable of handling conditions where packets are received out of chronological order.
  • the ESP device has a configurable Anti-Replay Window (ARW) parameter.
  • the ARW defines the interval of time where the ESP device will accept a packet whose time stamp is older than the previously received packet from the same source. Otherwise, received packets whose time stamps are older than the previously received packet from the same source are discarded.
  • a smaller ARW value provides tighter protection against replay attack. A larger value loosens the security, but will allow for more flexible network operation.
  • a typical default value of the ARW parameter is on the order of a couple of seconds.
  • the radios instead of having static IP addresses (meaning IP addresses that do not change over time), the radios have dynamically assigned IP addresses (meaning IP addresses that change over time), which are usually assigned through context activation.
  • IP addresses meaning IP addresses that change over time
  • access control methods for a radio to access the gateway device, and hence the application service of the enterprise network do not address access control when IP addresses are dynamically assigned.
  • an embodiment of the present disclosure provides access control for radios having dynamically assigned IP addresses.
  • the radio is authorized to use a VPN based upon the settings of the security gateway's access control list.
  • the security gateway's access control list contains the radio IDs of all authorized radios and may also contains a unique MAC key for each radio through OTAR provisioning or Key Fill. Accordingly, the security gateway verifies the received radio ID (e.g., from message 206 or 306) to the stored radio IDs. If there's a match and upon successful security session completion, the radio is authorized to use the VPN via the security gateway, and the dynamically assigned IP address (which is now an authorized IP address) is stored for that radio and associated with (or mapped to) the radio's stored ID. Since a radio ID is not present in later IPsec messages, the security gateway allows or authorizes VPN traffic to and from radios that have authorized IP addresses. The filtering can be performed based on IP addresses since each message contains the radio's IP address.
  • relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
  • the terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
  • a device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
  • processors or “processing devices”
  • the non- processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method to perform the secure packet transmission described herein.
  • some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic.
  • ASICs application specific integrated circuits
  • Both the state machine and ASIC are considered herein as a "processing device" for purposes of the foregoing discussion and claim language.
  • an embodiment can be implemented as a computer-readable storage element or medium having computer readable code stored thereon for programming a computer (e.g., comprising a processing device) to perform a method as described and claimed herein.
  • Examples of such computer-readable storage elements include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention se rapporte à une passerelle de sécurité et à un dispositif initiateur qui exécutent des procédés adaptés pour établir une session sécurisée. Les procédés selon l'invention consistent en ce que la passerelle de sécurité : reçoit un premier message d'un dispositif initiateur, le premier message contenant un premier code d'authentification de message ; elle valide le premier message au moyen du code d'authentification de message ; et, en réponse à la validation, elle envoie un second message au dispositif initiateur. Le second message contient une estampille temporelle et il contient par ailleurs un second code d'authentification de message destiné à permettre au dispositif initiateur d'authentifier l'estampille temporelle. La présente invention est caractérisée en ce que : les premier et second messages sont utilisés pour établir la session de sécurité ; et l'estampille temporelle authentifiée est utilisée pour protéger des relectures consécutives de messages entre la passerelle de sécurité et le dispositif initiateur. Le procédé consiste d'autre part en ce que la passerelle de sécurité valide une adresse IP attribuée de façon dynamique, cette adresse IP devant être utilisée par le dispositif initiateur pour autoriser un trafic VPN entre les deux dispositifs.
PCT/US2011/045196 2010-08-08 2011-07-25 Procédés adaptés pour établir une session sécurisée dans un système de communication WO2012021284A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA2807499A CA2807499C (fr) 2010-08-08 2011-07-25 Procedes adaptes pour etablir une session securisee dans un systeme de communication
AU2011289780A AU2011289780A1 (en) 2010-08-08 2011-07-25 Methods for establishing a security session in a communication system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US37173510P 2010-08-08 2010-08-08
US61/371,735 2010-08-08
US13/174,324 2011-06-30
US13/174,324 US20120036567A1 (en) 2010-08-05 2011-06-30 Methods for establishing a security session in a communications system

Publications (3)

Publication Number Publication Date
WO2012021284A2 true WO2012021284A2 (fr) 2012-02-16
WO2012021284A3 WO2012021284A3 (fr) 2012-04-12
WO2012021284A4 WO2012021284A4 (fr) 2012-06-07

Family

ID=45568118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2011/045196 WO2012021284A2 (fr) 2010-08-08 2011-07-25 Procédés adaptés pour établir une session sécurisée dans un système de communication

Country Status (3)

Country Link
AU (1) AU2011289780A1 (fr)
CA (1) CA2807499C (fr)
WO (1) WO2012021284A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014031015A1 (fr) * 2012-08-24 2014-02-27 Motorola Solutions, Inc. Procédé et appareil d'authentification d'informations numériques

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080126559A1 (en) * 2006-11-29 2008-05-29 Uri Elzur METHOD AND SYSTEM FOR SECURING A NETWORK UTILIZING IPSEC and MACSEC PROTOCOLS

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080126559A1 (en) * 2006-11-29 2008-05-29 Uri Elzur METHOD AND SYSTEM FOR SECURING A NETWORK UTILIZING IPSEC and MACSEC PROTOCOLS

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
A. MENEZES ET AL. HANDBOOK OF APPLIED CRYPTOGRAP HY 1996, *
SHEILA FRANKEL ET AL. GUIDE TO IPSEC VPNS: RECOMMENDATIONS OF THE NAT IONAL INSTITUTE OF STANDARDS AND TECHNOLOGY December 2005, *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014031015A1 (fr) * 2012-08-24 2014-02-27 Motorola Solutions, Inc. Procédé et appareil d'authentification d'informations numériques
GB2518577A (en) * 2012-08-24 2015-03-25 Motorola Solutions Inc Method and apparatus for authenticating digital information
US10064063B2 (en) 2012-08-24 2018-08-28 Motorola Solutions, Inc. Method and apparatus for authenticating digital information
GB2518577B (en) * 2012-08-24 2019-12-04 Motorola Solutions Inc Method and apparatus for authenticating digital information

Also Published As

Publication number Publication date
WO2012021284A4 (fr) 2012-06-07
CA2807499C (fr) 2014-08-19
CA2807499A1 (fr) 2012-02-16
AU2011289780A1 (en) 2013-02-28
WO2012021284A3 (fr) 2012-04-12

Similar Documents

Publication Publication Date Title
US20120036567A1 (en) Methods for establishing a security session in a communications system
EP2950506B1 (fr) Procede permettant d'etablir un canal de communication securise
Tschofenig et al. Transport layer security (tls)/datagram transport layer security (dtls) profiles for the internet of things
Sheffer et al. Recommendations for secure use of transport layer security (tls) and datagram transport layer security (dtls)
EP2272271B1 (fr) Procédé et système pour l'authentification mutuelle de noeuds dans un réseau de communication sans fil
US8285990B2 (en) Method and system for authentication confirmation using extensible authentication protocol
Cam-Winget et al. The flexible authentication via secure tunneling extensible authentication protocol method (EAP-FAST)
EP2656648B1 (fr) Établissement de clé assisté par opérateur
US20070143614A1 (en) Method, system and devices for protection of a communication or session
CN103079200A (zh) 一种无线接入的认证方法、系统及无线路由器
WO2007059558A1 (fr) Protocole sans fil pour confidentialité et authentification
US20220263811A1 (en) Methods and Systems for Internet Key Exchange Re-Authentication Optimization
Fossati RFC 7925: Transport Layer Security (TLS)/Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
WO2023036348A1 (fr) Procédé et appareil de communication chiffrée, dispositif et support de stockage
WO2015180399A1 (fr) Procédé, dispositif et système d'authentification
Alhakami et al. A secure MAC protocol for cognitive radio networks (SMCRN)
CN114500013A (zh) 一种数据加密传输方法
JP2011045064A (ja) 無線通信システムにおけるデータの完全性検査のためのオーバーヘッドを低減させるための方法及び装置
CN113973001A (zh) 一种认证密钥的更新方法及装置
CN112714507A (zh) 一种无线自组网间数据安全传输的方法
CA2807499C (fr) Procedes adaptes pour etablir une session securisee dans un systeme de communication
Zhou et al. Tunnel Extensible Authentication Protocol (TEAP) Version 1
Wei-min et al. A simple key management scheme based on WiMAX
KR20110087972A (ko) 세션 테이블을 이용한 비정상 트래픽의 차단 방법
Eren et al. WiMAX-Security–Assessment of the Security Mechanisms in IEEE 802.16 d/e

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11816781

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase in:

Ref document number: 2807499

Country of ref document: CA

NENP Non-entry into the national phase in:

Ref country code: DE

ENP Entry into the national phase in:

Ref document number: 2011289780

Country of ref document: AU

Date of ref document: 20110725

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 11816781

Country of ref document: EP

Kind code of ref document: A2