|Publication number||US6912657 B2|
|Application number||US 09/789,230|
|Publication date||Jun 28, 2005|
|Filing date||Feb 20, 2001|
|Priority date||Feb 22, 2000|
|Also published as||DE60011990D1, DE60011990T2, EP1128597A1, EP1128597B1, US20010016909, WO2001063833A1|
|Publication number||09789230, 789230, US 6912657 B2, US 6912657B2, US-B2-6912657, US6912657 B2, US6912657B2|
|Original Assignee||Telefonaktiebolaget Lm Ericsson|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Non-Patent Citations (1), Referenced by (26), Classifications (20), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates to the field of communication networks and more specifically to an ad hoc communication network and a method for establishing a security association in an ad hoc network.
The fast growth of open networks with easy access has raised many security problems. Several security solutions for public networks like the Internet have appeared. Security is a problem in all kinds of open networks both wired and wireless. Information transmitted over the air is extremely vulnerable. Security solutions can be based on pure symmetric key techniques or can be a combination of symmetric and asymmetric, so-called public key techniques. Common solutions today are built upon some type of so called Public Key Infrastructure (PKI). A public key infrastructure is a system used to distribute and check public keys that can be used to authenticate users, exchange session keys, sign information or encrypt information.
A symmetric key establishing scheme is built on that some a priori secret is known by the involved parties in advance. In principle there are two types of systems, key establishment between two parties sharing a common secret and key establishment by using a third party, a Key Distribution Center (KDC). A typical requirement in any security application is performing mutual authentication and key exchange. If the two involved parties, like in the first system, are pre-configured with a common shared secret this can be obtained by using a standard symmetric key authentication and key exchange protocol.
A well-known example of the latter system is the Kerberos protocol. A Keberos system is shown in a schematic block diagram in
The advantage with a system like the Kerberos system compared to mutual exchange is that each entity only needs to share one long lived key with the KDC. There is no need to share keys with all parties in the network. The only entity that needs to store several long-lived keys is the KDC.
In a PKI system, two corresponding (also called asymmetric) keys are used in connection with protecting information. Information, which is encrypted with one of the two keys, can be decrypted only with the other key. In some PKI systems either of the two keys can be used to encrypt and the other to decrypt. In other systems, one key must be used only for encryption and the other for decryption. One important feature of PKI systems is that it is computationally unfeasible to use knowledge of one of the keys to deduce the other key. In a typical PKI system, each of the systems possesses a set of two such keys. One of the keys is maintained private while the other is freely published. If a sender encrypts a message with the recipient's public key, only the intended recipient can decrypt the message, since only the recipient is in possession of the private key corresponding to the published public key. If the sender, before performing the above encryption, first encrypts the message with the senders private key, the recipient, upon performing first a decryption, using the recipient's private key, then a decryption on the result, using the sender's public key, is assured not only of privacy but of authentication since only the sender could have encrypted a message such that the sender's public key successfully decrypts it. In one digital signature scheme, one-way hash is first applied to a message and the hash of the message is encrypted with the sender's private key.
A PKI distributes one or several public keys and determine whether a certain public key can be trusted for certain usage or not. A piece of digitally signed information is often called a certificate. Certificates are the basis upon which PKIs are built.
The degree of confidence that the recipient has in the source of a message depends on the degree of the recipient's confidence that the sender's public key corresponds to a private key that was possessed only by the sender. In many current systems, a number of generally well trusted certification authorities have been established to provide this degree of confidence.
A common certificate format is Standard X.509 (developed by the International Standards Organisation (ISO) and the Comité Consultatif Internationale Telegraphique et Telephonique (CCITT)). Such a certificate may, e.g., include a public key, the name of subject who possesses or is associated with the public key, an expiration date, all of which are digitally signed by a trusted party. The digital signature may be provided e.g., according to the digital signature standard (DSS) (National Institute of Standards and Technology (NIST)). Typically a digital signature involves applying a one-way hash and then encrypting with the private key of, in this case, the certification authority. Such digital signature is provided using the private key of the trusted party which, in turn, is authenticated using the trusted party's certificate signed by yet another trusted party, so that there may be a multi-level hierarchy of trusted parties.
Another certificate format is Pretty Good Privacy (PGP) developed by P. Zimmermann and described in Internet Engineering Task Force (IETF) Open PGP Specification. PGP provides a way to encrypt and decrypt, sign data and exchange keys. Thus it is more than just a PKI. However, the main idea with PGP is that no strict PKI is needed. Instead the PGP users themselves create and extend the PKI they need. This is done by certifying other users public keys, i.e., signing trusted public keys with their own secret key. In this way a “web of trust” is created. A particular key may have several different user IDs. Typically a user ID is an email address. If a revocation signature follows a key, the key is revoked. A user certifies another users key by signing it with one of the keys of his own, which has signing capability. When signing another key, different trust levels can be set, i.e., the amount of confidence the signer has in the signed key and user ID.
Today, so-called ad hoc networks are used more and more frequently. An ad hoc network is established temporary for a special purpose. There is no fixed infrastructure; the nodes are the network. The nodes within the network are often mobile and using radio links. An ad hoc network might constitute dynamic wide area connectivity in situations such as military operations, rescue and recovery operations, and remote construction sites. An ad hoc network might also constitute local area connectivity in situations such as temporary conference sites, home networks and robot networks. An ad hoc network might also constitute personal area networks in situations such as interconnected accessories, ad hoc conference table and games. The nodes might consist of e.g. mobile phones, lap tops, television sets, washing machines In some situations like in military operations or business conferences when the communication between the nodes comprises secrets, it is very important that a sender of a message can trust that the receiver really is the intended receiver.
In the previous examples, bindings between public keys and names or authorisation are described. Several of these certificate solutions exist in different systems. However, it is not yet described how different certificates needed for different kinds of purposes are obtained. In the case of ordinary X.509 type of PKI with hierarchical Certificate Authority (CA) structures, finding the right certificate is done using some central on-line server or by direct transmission of the certificate at connection set up. When using PGP either the desired public key is stored locally on a machine or the device has to make a connection to a central PGP server in order to find the desired pubic key. This works if it is possible for entities that need some type of security relation to have on-line connections to some particular servers. This is not the case for ad hoc networks. Ad hoc networks are created on the fly between entities that happen to be at the same physical location.
Although all the security techniques described earlier are very powerful and allow smooth and automatic security for many different use cases, they all have some problem when it comes to the special situation of human faces in an ad hoc network.
Three different ad hoc scenarios will illustrate the shortcomings of the related art described above regarding ad hoc security establishment.
In the first scenario several people gather together in a conference room and would like to share some information. Everybody in the conference room has a communication unit such as a laptop or a Personal Data Assistant (PDA) with wireless access to all the other people in the room. The people in the room have not been in contact with each other previously. Now they would like to share some secret information using a certain application in their device. How can this be achieved?
In the second scenario, a person arrives at a new geographical location and comes to some vendor machine offering him or her some type of service, e.g. like a ticket or some food. The person has a paying device with a wireless connection to the vendor machine. The company and the person have no previous relation to each other. How can a person transmit an electronic paying transaction (and thereby receive some product from the machine) to the vendor machine over the air interface?
Two different devices, e.g. a mouse and a Personal Computer (PC), from two different vendors are connected to each other over a wireless link, in the third scenario. A person would like to “pair” these two devices so that they can communicate securely over the wireless link How can this be done in a user friendly and efficient way?
The symmetric key based key sharing mechanisms described above, all demands that some secret information is shared between the devices that want to communicate. At least there must be a secure chain like in Kerberos system that can be used to create a trust relation between two devices. A secure chain is e.g. when A and B do not trust each other, but A and C trust each other, and B and C trust each other so A and B can get a trust relationship via C. This is often hard to achieve for the first and second ad hoc scenario. Anyway, it would be very cumbersome to manually enter some secret information to all devices in the first scenario. In the third scenario it would be possible to enter some secret symmetric information into the two devices that the person would like to “pair” This is for example what is used in the security solution of the Bluetooth standard. However that means that if the device has no input channel, e.g. a mouse, a microphone etc., it must be pre configured with the secret information and this information must be kept secret Otherwise, anybody can make a pairing of the device. Furthermore, if the security level should be kept, the secret key of some certain device must be kept physically apart from the device. It is hard for humans to remember several Personal Identification Number (PIN) codes or to store them in a good and secure way.
A public key based system like the ones described above do not fit well into any of the scenarios described. If it should be possible to use a X.509 like certificate or a PGP key, a trusted party must sign the public key. In the first and second scenario it is not always assumed that the parties share trusted public keys or have certificates signed by a third party that each party trust Also in the third scenario, certificates and public keys can not be used without some trust in the signature of the certificate or a public key and since the devices can come from any source it might be very hard to administrate distribution of trusted certificates to all possible devices.
Therefore, what is further needed is a way of making communications within an ad hoc network more secure.
The present invention relates to the requirement of security in an ad hoc network More particularly it relates to the problem of establishing of security that arises within an ad hoc network.
The problems discussed are:
The symmetric key based key sharing mechanisms described above, all demands that some secret information is shared between the devices that want to communicate. This is often hard to achieve in ad hoc networks.
A public key based system like the ones described above do not fit well into ad hoc networks, since a trusted party must sign the public key. It is unusual that the parties in an ad hoc network share trusted public keys or have certificates signed by a third party that each party trust.
Accordingly, it is an object of the present invention to unravel the above-mentioned problem.
The solution, according to the invention is to use an optical device to read a public key that is encoded to a graphical string, which key is required for establishing security.
An ad hoc communications network according to the invention includes a first device and a second device. These devices are communication devices, which might be a laptop, a mobile phone, a printer, a vendor machine etc. The first device is equipped with an optical device. The second device has a pair of keys, the key pair constituting a secret key and a public key. The public key is hashed to a bit string which bit string is encoded to a graphical string. The graphical string is visible for the user of the first device. The first device has a user, e.g. the owner of the first device that trusts the second device. The first device wishes to authenticate the second device. The first device has means for reading the graphical string by means of the optical device and means for authenticating the second device by means of the read string including the public key. An ad hoc communications network according to this first aspect of the invention is hereby characterised by what are the features of claim 1.
A method for establishing a security relation between a first device and a second device within an ad hoc communications network according to a second aspect of the invention, includes the steps of:
A method according to this second aspect of the invention is hereby characterised by what are the features of claim 6.
An advantage of the present invention is that it is possible to achieve the necessary security associations needed for distributing and sharing information among a group of users that happens to be at the same physical location. There are a large amount of applications that fits in to this scenario. Among those can be mentioned people from different companies or organisations that gather in a conference room can share documents with the meeting members.
Another advantage of the present invention is that the number of manually created trust relations between members in an ad hoc communication network is decreased.
Yet another advantage of the present invention is that it makes it possible “pairing” devices in a secure way also in the case of a device lacking input channel
Yet another advantage of the present invention is that since the user physically interacts with the other device to get the trusted key, it is easier for the user to decide whether to trust a device or not.
Yet another advantage of the present invention is that due to the simplicity of the solution, also people without much understanding of the rather complicated mathematics or principles of public keys, can make secure connections with their devices.
Further scope of applicability of the present invention will become apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.
The ad hoc communications network according to the invention constitutes e.g. a bluetooth network or a Wireless Local Area Network (WLAN). The ad hoc network comprises devices constituting e.g. Personal Data Assistants PDAs, lap tops, mice, mobile phones, vendor machines, paying devices, etc. each device comprising communication means. The devices are interconnected via communication links.
The first device A also has a person that uses it, a user UA, e.g. the owner of the device.
The user UA wishes to communicate with a second device B within the network N. The second device B has a wireless access to other devices within the network and it might be e.g. a laptop, a vendor machine, a service device etc. The second device B might also have a user UB or might not, as in the case of constituting a vendor machine or a service device. The second device B has one or several secret key-public key pairs. The public key might be contained in a certificate signed by a third party. The public key or certificate that an arbitrary device would like to use to authenticate itself towards the second device B and /or exchange keys, is hashed, using a cryptographic strong one-way-function (see A. J. Menzes, P. C. van Orschot and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1997) to a large enough (to provide enough cryptographic strength) bit string. The bit string is mapped by a one-to-one code to a suitable graphical string S, that is readable for the optical device O. The graphical string S in some way visible for the user AU and the first device A, it might be printed on a card carried by the owner or user UB of the second device B, or it might be displayed on a slip, possibly electronic, physically attached to the second device B.
The user UA requires to create a security association between his own first device A and the second device B. The user AU, who trusts the graphical string S, reads the graphical string S with the optical device O. The user UA trusts the graphical string e.g. if it is printed on a card that he got from user UB who he knows or trusts by any other means, or by recognising a trustworthy company trademark of a vendor machine on which the slip, displaying the graphical string, is attached. To simplify for a user to trust a slip displaying a string it can be constructed so that it is easy for a user to see that nobody has manipulated the slip or that there is some electronic protection of the slip that disables the second device B if somebody manipulates the slip.
The read graphical string is transmitted from the optical device O to the first device A in a secure way, if they are in different entities.
The first device A gets the graphical string. If later the device receives a public key or a certificate containing the public key that can be hashed to the string S, that public key or certificate will be treated as trusted.
The first device A contacts the second device B and performs the security protocol. The security protocol used for authentication and shared key generation can be of any standard type like the Transport Layer Security (TLS) handshake protocol or the Internet Key Exchange Protocol (IKE).
The first device A authenticates the second device B using the public key that S is a graphical string of If the second device B is able to proof that it holds a secret key corresponding to the public key that S is a graphical string of, the second device B is trusted by the first device A.
It is possible for the user UA to decide for how long and to what extend a public key corresponding to the graphical string should be trusted. In many situations this trust relation might last for a very short time period.
In another example, both the first and the second devices A and B have a respective optical device and a respective key pair encoded into a respective graphical string being visible. So if the connection between the first device A and the second device B is a mutual trusted connection, The first and the second device A and B exchange secret session keys using trusted public keys.
In an embodiment of the present invention the second device B constitutes a service device which has a network address. The service device C might be a printer, a camera, a projector, a pay machine etc. The first device A which wishes to connect to the service device requires the network address. According to the present invention the graphical string S is mapped to the network address of the service device B. When the first device A reads the graphical string S by means of the optical device O, it obtains the public key, but also the network address of the service device B.
The first device having an optical device and the second device having a pair of keys constituting a secret key and a public key.
The first device has a user that trusts the second device.
The method comprises the following steps:
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4814979 *||Jul 16, 1985||Mar 21, 1989||Teradata Corporation||Network to transmit prioritized subtask pockets to dedicated processors|
|US5764772 *||Dec 15, 1995||Jun 9, 1998||Lotus Development Coporation||Differential work factor cryptography method and system|
|US5818937||Aug 12, 1996||Oct 6, 1998||Ncr Corporation||Telephone tone security device|
|EP0802654A2||Apr 18, 1997||Oct 22, 1997||Canon Kabushiki Kaisha||Enciphering method, deciphering method and certifying method|
|EP0977397A2||Jul 20, 1999||Feb 2, 2000||Lucent Technologies Inc.||Method for transferring sensitive information using initially unsecured communication|
|1||International Search Report as Completed on Aug. 1, 2001, by the ISA/EP in connection with PCT/EP01/01674.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7292842 *||Jan 30, 2004||Nov 6, 2007||Sony Corporation||Wireless adhoc communication system, terminal, authentication method for use in terminal, encryption method, terminal management method, and program for enabling terminal to perform those methods|
|US7426746 *||Oct 22, 2003||Sep 16, 2008||Nokia Corporation||Location privacy in a communication system|
|US7457848 *||Aug 27, 2002||Nov 25, 2008||Sony Corporation||Over-network resource distribution system and mutual authentication system|
|US7499443||Dec 5, 2006||Mar 3, 2009||Sony Corporation||Wireless adhoc communication system, terminal, authentication method for use in terminal, encryption method, terminal management method, and program for enabling terminal to perform those methods|
|US7567562 *||Jul 28, 2009||Panasonic Corporation||Content based secure rendezvous chaotic routing system for ultra high speed mobile communications in ad hoc network environment|
|US7716467 *||Dec 2, 2005||May 11, 2010||Sprint Communications Company L.P.||Encryption gateway service|
|US7899187 *||Nov 27, 2002||Mar 1, 2011||Motorola Mobility, Inc.||Domain-based digital-rights management system with easy and secure device enrollment|
|US8094822 *||Feb 3, 2004||Jan 10, 2012||Sony Corporation||Broadcast encryption key distribution system|
|US8219434 *||Jul 19, 2005||Jul 10, 2012||Sap Ag||Ad-hoc coordination actions in business processes|
|US8542834 *||Aug 9, 2007||Sep 24, 2013||Motion Computing, Inc.||System and method for securely pairing a wireless peripheral to a host|
|US8549513||Jun 29, 2005||Oct 1, 2013||Microsoft Corporation||Model-based virtual system provisioning|
|US8621210||Jun 26, 2008||Dec 31, 2013||Microsoft Corporation||Ad-hoc trust establishment using visual verification|
|US8726022 *||Aug 5, 2003||May 13, 2014||China Iwncomm Co., Ltd||Method for the access of the mobile terminal to the WLAN and for the data communication via the wireless link securely|
|US9215075||Mar 14, 2014||Dec 15, 2015||Poltorak Technologies Llc||System and method for secure relayed communications from an implantable medical device|
|US9317270||Sep 30, 2013||Apr 19, 2016||Microsoft Technology Licensing, Llc||Model-based virtual system provisioning|
|US20030078894 *||Aug 27, 2002||Apr 24, 2003||Masashi Kon||Over-network resource distribution system and mutual authentication system|
|US20040103312 *||Nov 27, 2002||May 27, 2004||Thomas Messerges||Domain-based digital-rights management system with easy and secure device enrollment|
|US20040111601 *||Dec 6, 2002||Jun 10, 2004||Nokia Corporation||System and method for the exchange of cryptographic keys|
|US20040259529 *||Jan 30, 2004||Dec 23, 2004||Sony Corporation||Wireless adhoc communication system, terminal, authentication method for use in terminal, encryption method, terminal management method, and program for enabling terminal to perform those methods|
|US20050055576 *||Oct 22, 2003||Mar 10, 2005||Risto Mononen||Location privacy in a communication system|
|US20050123141 *||Feb 3, 2004||Jun 9, 2005||Hideyuki Suzuki||Broadcast encryption key distribution system|
|US20060015382 *||Jul 19, 2005||Jan 19, 2006||Joerg Beringer||Ad-hoc coordination actions in business processes|
|US20060143458 *||Aug 5, 2003||Jun 29, 2006||Manxia Tie||Method for the access of the mobile terminal to the wlan and for the data communication via the wireless link securely|
|US20060198367 *||Mar 2, 2005||Sep 7, 2006||Matsushita Electric Industrial Co., Ltd.||Content based secure rendezvous chaotic routing system for ultra high speed mobile communications in ad hoc network environment|
|US20070101142 *||Dec 5, 2006||May 3, 2007||Sony Corporation|
|US20090319600 *||Dec 24, 2009||Boaz Sedan||Optimizing program requests over a wide area network|
|U.S. Classification||713/171, 380/285, 726/5, 380/278, 380/283|
|International Classification||H04L12/56, H04L9/32, H04L9/30, H04L12/28, H04L29/06|
|Cooperative Classification||H04W12/06, H04L2209/80, H04L2209/56, H04L9/3236, H04L63/0823, H04W84/18|
|European Classification||H04L63/08C, H04L9/30, H04L9/32, H04W12/00|
|Feb 20, 2001||AS||Assignment|
Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), SWEDEN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GEHRMANN, CHRISTIAN;REEL/FRAME:011563/0118
Effective date: 20010117
|Nov 20, 2007||CC||Certificate of correction|
|Dec 29, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Dec 28, 2012||FPAY||Fee payment|
Year of fee payment: 8