WO2010004354A1 - Gestion de clé dans un réseau d'accès - Google Patents

Gestion de clé dans un réseau d'accès Download PDF

Info

Publication number
WO2010004354A1
WO2010004354A1 PCT/IB2008/001792 IB2008001792W WO2010004354A1 WO 2010004354 A1 WO2010004354 A1 WO 2010004354A1 IB 2008001792 W IB2008001792 W IB 2008001792W WO 2010004354 A1 WO2010004354 A1 WO 2010004354A1
Authority
WO
WIPO (PCT)
Prior art keywords
network device
server node
message
key
network
Prior art date
Application number
PCT/IB2008/001792
Other languages
English (en)
Inventor
Kim Hyldgaard
Kjeld Flarup Christensen
Jorgen Karkov
Original Assignee
Telefonaktiebolaget L.M. Ericsson (Publ)
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
Application filed by Telefonaktiebolaget L.M. Ericsson (Publ) filed Critical Telefonaktiebolaget L.M. Ericsson (Publ)
Priority to PCT/IB2008/001792 priority Critical patent/WO2010004354A1/fr
Publication of WO2010004354A1 publication Critical patent/WO2010004354A1/fr

Links

Classifications

    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Definitions

  • the present invention relates to the field of data security and, more specifically, to the field of key management.
  • key management The distribution of the shared information (i.e., key) is sometimes referred to as "key management.”
  • the techniques involving trusted third parties are typically implemented in high-end solutions where the two communicating entities can communicate through a secure channel, even if they've never met and even if they have no prior knowledge of each other. They rely on the trusted third party to verify the authenticity of each other. This trusted third party can either be in-line, on-line or off-line with respect to the communication.
  • the pre-distributed keys techniques imply that each communicating entity has to have some kind of pre- distributed knowledge in order for that entity to authenticate itself towards the other party to the communication.
  • the pre-distributed keys are typically programmed during a production or installation phase.
  • the establishment techniques rely on some kind of special behavior, hi the resurrecting duckling technique, the communicating entity simply trusts the first other entity that it communicates with.
  • One of the reasons for the many different key management techniques is the difference among the large number of applications that require secure data communication. Applications running on a PC platform communicating through a wired connection to the internet are suited for one key management technique, whereas wireless communication between a temperature sensor and its base station is suited for another key management technique.
  • DSL network built in a tree topology poses some problems if the existing solutions are used. For example, pre-distributing keys will pose a big network management challenge due to the number of nodes that require the key. Programming the same key in all nodes would be easy to manage, but the security of the system relies on the secrecy of the common key. The loss would be catastrophic if the key somehow ended on the front page of a morning newspaper. Having an on-line trusted third party in the network (e.g. the Kerberos scheme) would also work, but this would require a new type of node in the network, which is not preferable. Furthermore, this node hosting the on-line trusted party would then be a single point of failure, which is also seen as a problem.
  • on-line trusted third party e.g. the Kerberos scheme
  • the resurrecting duckling technique is not adequate as the "resurrecting" node will accept the first device it discovers. After this authentication, the node cannot communicate with other server nodes. Thus it is impossible to move the node after it has been installed. In short, it has not been possible to find a solution that (a) provides adequate security, (b) does not require extra nodes in the network, (c) does not impose big challenges for producing and/or installing the nodes, and (d) enables nodes to be moved without having to reconfigure the nodes.
  • the key management solution should be able to handle nodes that do not have any security capabilities (e.g., a node that is not able to establish any form of secure communication and not programmed with some unique information that could be used as an initial key).
  • an embodiment of the invention provides a method for providing to a network device computer software that may be used by the device to obtain a key.
  • the method includes the following steps. The method may begin when a root node receives a message transmitted from a network device.
  • the message may include an identifier identifying the network device (the message may be a DHCP message that was transmitted to a broadcast address).
  • the root node may (1) determine whether the message was received within a predefined time window and/or (2) determine whether an identifier identifying the network device is included in a predefined list of network device identifiers, and/or (3) receive an indication from a network operator that the network device is accepted.
  • the root node may transmit the computer software to the network device, wherein the computer software is configured to enable the network device to obtain a key from a server node, wherein the transmitting step occurs only if (1) the message was received within the predefined time window, (2) an identifier identifying the network device is included in the predefined list of network device identifiers, and/or (3) (3) the indication from the network operator that the network device is accepted is received.
  • the device may use the computer software in the establishment of a secured connection (e.g., a secured connection established using the IPsec ESP protocol or other protocol that provides privacy) with the server node.
  • a secured connection e.g., a secured connection established using the IPsec ESP protocol or other protocol that provides privacy
  • a key may be transmitted to the network device using the secured connection.
  • the network device may use this key to encrypt data transmitted through a network or may use the key to be authenticated by the server.
  • the network device is a multiplexer (e.g., a digital subscriber line access multiplexer (DSLAM)).
  • DSLAM digital subscriber line access multiplexer
  • the present invention provides a method of providing a key to a network device that already has computer software for establishing secured connections.
  • the method includes the following steps. First, the server node may receive a message transmitted from the network device. Next, after receiving the message, the server (1) determines whether the message was received within a predefined time window, (2) determines whether an identifier identifying the network device is included in a predefined list of network device identifiers, and/or (3) receives an indication from a network operator that the network device is accepted.
  • the server transmits the key to the network device.
  • the message includes an identifier identifying the network device and the step of determining whether an identifier identifying the network device is included in the predefined list of network device identifiers comprises determining whether the identifier included in the message is included in the predefined list of network device identifiers.
  • the method further includes one or more of: encrypting the key prior to transmitting the key to the network device; transmitting the message from the network device to the server node, wherein the transmitting step occurs in response to an initialization of the network device; and
  • the step of establishing the secured connection comprises establishing the secured connection without using any secure information that is shared between the server node and the network device.
  • the step of establishing the secured connection may include establishing a secured tunnel and/or exchanging public keys.
  • Some of the advantages of the above described method are that it (a) provides adequate security, (b) does not require extra nodes in the network, (c) does not impose big challenges for producing and/or installing the nodes, and (d) enables nodes to be moved without having to reconfigure the nodes.
  • the invention provides a server node configured to perform at least some of the above described functions.
  • the server node includes: a receiver operable to receive from a network device a message comprising an identifier identifying the network device; determining means for determining (1) whether the received message was received within a predefined time window, (2) whether an identifier identifying the network device is included in a predefined list of network device identifiers, and/or (3) whether a network operator has indicated that the network device is accepted; and a transmitter operable to transmit to the network device computer software configured to enable the network device to obtain a key from the server node.
  • the server node is configured to transmit the computer software to the network device only if (1) the determining means determines the received message was received within the predefined time window, (2) the determining means determines that an identifier identifying the network device is included in the predefined list of network device identifiers, and/or (3) the determining means determines that the network operator indicated that the device is accepted.
  • the computer software is further configured to enable the network device to establish a secured connection with the server node, and the server node is further configured to transmit a key to the network device using the secured connection.
  • the secured connection may be established using the IPsec ESP protocol or other protocol.
  • server node Some of the advantages of the above described server node are that it (a) provides adequate security, (b) does not require extra nodes in the network,
  • the server node includes: a receiver operable to receive a message transmitted from the network device; determining means for (1) determining whether the received message was received within a predefined time window, (2) determining whether an identifier identifying the network device is included in a predefined list of network device identifiers, and/or (3) determining whether a network operator has indicated that the network device is accepted; and a transmitter operable to transmit a key to the network device.
  • the server node is configured to transmit the key to the network device only if (1) the determining means determines the received message was received within the predefined time window, (2) the determining means determines that an identifier identifying the network device is included in the predefined list of network device identifiers, and/or (3) the determining means determines that the network operator has indicated that the network device is accepted.
  • the message comprises an identifier identifying the network device and the determining means is configured to determine whether an identifier identifying the network device is included in the predefined list of network device identifiers by determining whether the identifier included in the message is included in the predefined list of network device identifiers.
  • the network device is configured to transmit the message to the server node in response to an initialization of the network device, and the server node is configured to establish a secured connection with the network device, and the network device is configured to transmit the message to the server node after the secured connection is established.
  • the server node may establish the secured connection without using any secure information that is shared between the server node and the network device. For example, the server node may establish the secured connection by establishing a secured tunnel and/or exchanging public keys.
  • server node Some of the advantages of the above described server node are that it (a) provides adequate security, (b) does not require extra nodes in the network,
  • FIG. 1. illustrates components of an access network.
  • FIG. 2 is a flow chart illustrating a process according to some embodiments of the invention.
  • FIG. 3 is a flow chart illustrating a process according to some embodiments of the invention.
  • FIG. 4 is data flow diagram further illustrating a process according to some embodiments of the invention.
  • FIG. 5 is functional block diagram illustrating certain components of a server node according to some embodiments of the invention.
  • FIG. 6 is a flow chart illustrating a process according to some embodiments of the invention.
  • FIG. 1 illustrates an access network 100 in which embodiments of the present invention may be implemented.
  • access network may be a digital subscriber line (DSL) network.
  • network 100 may include a number of network devices 102. In the example shown, there are three network devices 102a, 102b and 102c. However, in practice, network 100 may include more than three network devices (e.g., network 100 may include hundreds of network devices 102).
  • each network device 102 may be a multiplexer (e.g., a DSL access multiplexer (DSLAM)).
  • FIG. 1 illustrates network devices 102 in communication with a server node 104.
  • DSL access multiplexer DSL access multiplexer
  • Server 104 may also be referred to as "root node” 104. While only a single server 104 is show, this was done merely for brevity as network 100 may include more than one server 104, additionally, server node 104 may be implemented using one or more computers. Server 104 may be in communication with a network management system (NMS) 106.
  • NMS network management system
  • devices 102 may be required to establish a secure communication channel with server 104 or with another device. Accordingly, in these embodiments, it may be required that each device 102 be provided with a key (a.k.a., a " key") for establishing the secure communication. Described below are methods according to some embodiments for managing key distribution in network 100.
  • FIG. 2 is a flow chart illustrating a process 200, according to some embodiments, for distributing a key to a network device (e.g., network device 102a).
  • network device 102a does not have the capability of establishing secure communication with server 104 (e.g., network device 102a, at least initially, has no ability to encrypt the data it sends to server 104 or to authenticate itself).
  • Process 200 may begin in step 202, where network device 102a is initialized (e.g., network device 102a completes a boot-up procedure).
  • device 102a transmits a message.
  • the message may be a request for an IP address that is sent to a broadcast address.
  • the message may be a dynamic host configuration protocol (DHCP) message.
  • DHCP dynamic host configuration protocol
  • step 206 root node 104 receives the message.
  • step 206 root node 104 receives the message.
  • root node 104 in response to the message, root node 104, among other things, (1) automatically determines whether the message was received within a predefined time window, (2) automatically determines whether an identifier identifying network device 102a is included in a predefined list of network device identifiers, and/or (3) displays to a network operator a user interface that enables the network operator to manually indicate that the network device is acceptable (e.g., the user interface may include an identifier identifying the device 102a and a checkbox next to the identifier that the network operator can check to indicate that the device 102a is acceptable). This step is performed in order to determine whether device 102a is a trusted device.
  • a network operator may specify that (1) any device 102 that transmits a particular message within a certain time period (e.g., between 1400 hrs and 1430 hrs on a particular day) and/or (2) is identified in a list of trusted devices is a trusted device (i.e., acceptable).
  • Node 104 may determine whether the message was received within the predefined time window by, for example, recording the time at which the message was received and
  • node 104 may determine whether the message was received within the predefined time window by, for example, checking the status of a certain flag at the time of receiving the message, wherein the certain flag may be set to TRUE during the time window and set to FALSE at all other times.
  • root node 104 transmits particular computer software (e.g., a particular computer program) to device 102a (step 210). That is, root node 104 transmits the computer software to device 102a only if device 102a is determined as being trusted by, for example, determining whether a particular message sent from device 102a was sent during a particular time period and/or determining whether an identifier identifying the device is included in a particular list and/or determining whether the network operator indicated manually that the device is acceptable.
  • the step of transmitting the software to device 102a may include pushing the software to device 102a or causing device 102a to pull the software.
  • step 210 The particular computer software transmitted to device 102a in step 210 is configured to enable device 102a to establish secure communications with another node and obtain a key from, for example, root node 104. Accordingly, after step 210 the process my proceed to step 302 or 304 of process 300 (see FIG. 3).
  • a device that initially does not have a capability to establish a secured connection can, in a secured manner, receive a key. Additionally, through use of the above described time- window and/or trusted list, a node (or an operator) can determine whether a device in network 100 should be considered trusted.
  • FIG. 3 is a flow chart illustrating a process 300, according to some embodiments, for distributing a key to a network device (e.g.,
  • Process 300 may begin in step 302, where network device 102b is initialized (e.g., network device 102b completes a boot-up procedure). As part of the boot-up procedure, device 102b may transmit a DHCP request, a response to which may be transmitted by node 104.
  • a secured connection is established between device 102b and node 104.
  • the secured connection may be established using an IPsec protocol (e.g., the encapsulating security payload (ESP) protocol).
  • ESP encapsulating security payload
  • step 310 node 104 determines (1) whether a message transmitted from device 102b was received within a predefined time window and/or (2) whether an identifier identifying network device 102b is included in a predefined list of network device identifiers (this may be accomplished by examining the list to determine whether the identifier included in the message received in step 308 is included in the list).
  • Step 310 is performed in order to determine whether device 102b is a trusted device. For example, a network operator may specify that a device is a trusted device only if (1) the device 102 transmits a particular message within a certain time period, (2) the device is identified in a list of trusted devices, the network operator manually indicates that the device is trusted.
  • root node 104 In response to determining that device 102b is a trusted device, root node 104, using the secured connection established in step 304, transmits a key to device 102b (step 312). For example, in step 312, root node 104 encrypts the key and transmits the encrypted key to device 102b.
  • the step of transmitting the key to device 102b may include pushing the key to device 102b or causing device 102b to pull the key.
  • step 314 immediately after the encrypted key is transmitted to device 102b and received by the device, the secured connection may be
  • step 316 device 102b decrypts the received encrypted key and establishes a second secured connection with the server node using the key (e.g., the network device uses the key in authenticating itself to the root node 104).
  • FIG. 4 The data flow diagram illustrated in FIG. 4, further illustrates the above described process according to some embodiments.
  • device 102b transmits a DHCP request, which is received at root node 104.
  • node 104 transmits a DHCP response.
  • a secured connection is established between the device and root node 104.
  • device 102b may transmit a message to node 104. Assuming (a) the message is received at a point in time within a predefined time- window and/or (b) an identifier identifying device 102b is included in a list of trusted nodes, then root node 104 sends the key to device 102b.
  • the secured connection can be disconnected.
  • the key enables a second secured connection to be established between the device and root node 104.
  • the device can use this second secured connection to transmit the sensitive data to root node 104 (e.g., the device can use the key to authenticate/encrypt data).
  • FIG. 6 is a flow chart illustrating a process 600 according to an embodiment of the invention.
  • Process 600 is a process performed by a network device (e.g., device 102c) that has previously received a key from root node 104.
  • Process 600 may begin in step 602, where network device 102c is initialized (e.g., network device 102c completes a boot-up procedure).
  • step 604 device 102c establishes a second secured connection with the server node using the previously received key (e.g., the network device uses the key to authenticate itself and then transmit encrypted and/or authenticated data).
  • FIG. 5 is a functional block diagram of a root node 104 according to some embodiments.
  • a root node 104 includes: transmit and receive components 505 and 502 for enabling node 104 to communicate with, among other things, devices 102; a data storage 506 (e.g., non- volatile memory, disk drive, etc) storing software 510; and a processor 508 for executing software 510.
  • Software 510 is configured such that, when it is executed by processor 508, it causes node 104 to perform one or more of the functions described herein.
  • processor 508 and the software 510 are the means that perform several of the functions described herein.
  • processor 508 and software 510 are the means for determining (1) whether the received message was received within a predefined time window, (2) whether an identifier identifying the network device is included in a predefined list of network device identifiers, and/or (3) whether a network operator has indicated that the network device is accepted.

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)
  • Mobile Radio Communication Systems (AREA)

Abstract

La gestion de clé est une composante importante dans la gestion d'un réseau de communication. Par exemple, il est important que des informations secrètes (par exemple, certaines clés) soient distribuées uniquement à des nœuds de confiance dans le réseau. Dans un aspect de la présente invention, la présente invention porte sur un procédé de distribution de clés. Dans un mode de réalisation, un distributeur de clé (par exemple, un nœud racine) qui met en œuvre un mode de réalisation du procédé distribuera une clé à un nœud demandeur seulement si (a) le nœud transmet un certain message à un instant qui tombe dans une fenêtre de temps prédéfinie, (b) un identifiant identifiant le nœud demandeur est inclus dans une liste prédéfinie de nœuds de confiance, et/ou (c) un opérateur de réseau indique que le nœud demandeur est accepté.
PCT/IB2008/001792 2008-07-08 2008-07-08 Gestion de clé dans un réseau d'accès WO2010004354A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2008/001792 WO2010004354A1 (fr) 2008-07-08 2008-07-08 Gestion de clé dans un réseau d'accès

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2008/001792 WO2010004354A1 (fr) 2008-07-08 2008-07-08 Gestion de clé dans un réseau d'accès

Publications (1)

Publication Number Publication Date
WO2010004354A1 true WO2010004354A1 (fr) 2010-01-14

Family

ID=40266098

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2008/001792 WO2010004354A1 (fr) 2008-07-08 2008-07-08 Gestion de clé dans un réseau d'accès

Country Status (1)

Country Link
WO (1) WO2010004354A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001029661A2 (fr) * 1999-10-18 2001-04-26 Wnf Consulting Procede et dispositif de maintenance d'un systeme informatique
WO2003054661A2 (fr) * 2001-12-12 2003-07-03 Valve Corporation Procede et systeme de securisation de contenu dans un systeme reparti
US20050138148A1 (en) * 2003-12-22 2005-06-23 At&T Corporation Signaling managed device presence to control security
US7231660B1 (en) * 1999-11-25 2007-06-12 International Business Machines Corporation Method and system for preventing unauthorized server interference in an internet protocol network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001029661A2 (fr) * 1999-10-18 2001-04-26 Wnf Consulting Procede et dispositif de maintenance d'un systeme informatique
US7231660B1 (en) * 1999-11-25 2007-06-12 International Business Machines Corporation Method and system for preventing unauthorized server interference in an internet protocol network
WO2003054661A2 (fr) * 2001-12-12 2003-07-03 Valve Corporation Procede et systeme de securisation de contenu dans un systeme reparti
US20050138148A1 (en) * 2003-12-22 2005-06-23 At&T Corporation Signaling managed device presence to control security

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"AutoInstall Using DHCP for LAN Interfaces", INTERNET CITATION, XP002210269, Retrieved from the Internet <URL:http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121ne wft/121t/121t5/dt_dhcpa.pdf> [retrieved on 20020819] *

Similar Documents

Publication Publication Date Title
US10009320B2 (en) Computerized system and method for deployment of management tunnels
KR101213870B1 (ko) 무선 장치의 발견 및 구성 방법을 수행하기 위한 컴퓨터실행가능 명령어들을 저장한 컴퓨터 판독가능 매체
US7809354B2 (en) Detecting address spoofing in wireless network environments
US8555344B1 (en) Methods and systems for fallback modes of operation within wireless computer networks
KR101086576B1 (ko) 보안 프로토콜의 자동 협상 시스템 및 방법
JP5607655B2 (ja) 非暗号化ネットワーク動作解決策
US20070079113A1 (en) Automatic secure device introduction and configuration
CN107124266B (zh) 基于量子加密的视频通信系统以及方法
US20040196977A1 (en) Conveying wireless encryption keys upon client device connecting to network in non-wireless manner
US20040143762A1 (en) Method and system for authenticating a personal security device vis-a-vis at least one remote computer system
CN106535089B (zh) 机器对机器虚拟私有网络
JP2005286783A (ja) 無線ｌａｎ接続方法および無線ｌａｎクライアントソフトウェア
KR20100044199A (ko) 트러스트 센터 링크 키를 초기화하는 네트워크 및 방법
JP4536051B2 (ja) 無線ｌａｎ端末を認証する認証システム、認証方法、認証サーバ、無線ｌａｎ端末、及びプログラム
JP2023506463A (ja) 暗号化通信装置および暗号化通信方法
WO2010004354A1 (fr) Gestion de clé dans un réseau d&#39;accès
JP2004266516A (ja) ネットワーク管理サーバ、通信端末、エッジスイッチ装置、通信用プログラム並びにネットワークシステム
US20240163664A1 (en) Secure key management device, authentication system, wide area network and method for generating session keys
CN116996587B (zh) 一种分布式sdp隧道控制方法及设备
EP4044553A1 (fr) Procédé et dispositif pour fournir un niveau de sécurité de communication
WO2023240587A1 (fr) Procédé et appareil de configuration de permissions de dispositif, et dispositif terminal
JP2007157008A (ja) 情報処理装置、ネットワーク設定方法、記憶媒体、プログラム
CN115037504A (zh) 通信方法及装置
KR20240000161A (ko) Dds 통신 방법, 장치 및 시스템
JP2023138927A (ja) データファイル送信及びデータファイルへのアクセス権を管理するためのシステム及び方法

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: 08788868

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08788868

Country of ref document: EP

Kind code of ref document: A1