One embodiment of the present invention provides a system that communicates cryptographic data through multiple network layers. During operation, the system receives the cryptographic data and divides the cryptographic data into multiple pieces. The system then encapsulates different pieces of the cryptographic data into fields associated with different network layers in a data packet, whereby an item of cryptographic data that is too large to be communicated in a single field can be communicated through multiple fields associated with different network layers.
|
33. An apparatus for verifying a data packet containing cryptographic data, comprising:
a receiving mechanism configured to receive the data packet;
an extracting mechanism configured to extract pieces of cryptographic data from fields associated with different network layers of a protocol stack within the data packet, wherein the cryptographic data is larger than a single field, and wherein the cryptographic data is simultaneously encapsulated within multiple fields; and
a verification mechanism configured to verify that each piece of extracted cryptographic data matches with a corresponding portion of a piece of previously obtain cryptographic data.
31. A method for verifying a data packet containing cryptographic data, comprising:
receiving the data packet;
extracting pieces of cryptographic data from fields associated with different network layers of a protocol stack within the data packet, wherein the cryptographic data is larger than a single field, and wherein the cryptographic data is simultaneously encapsulated within multiple fields; and
verifying that each piece of extracted cryptographic data matches with a corresponding portion of a piece of previously obtained cryptographic data;
wherein the multiple fields are received simultaneously to reconstruct an identity associated with the cryptographic data; and
wherein the multiple fields are simultaneously encapsulated into the data packet by a sending node to ensure that the data packet can be routed through a network to reach a receiving node.
1. A method for communicating cryptographic data through multiple network layers, comprising:
receiving the cryptographic data at a node;
dividing the cryptographic data into multiple pieces; and
simultaneously encapsulating different pieces of the cryptographic data in fields associated with different network layers of a protocol stack in a data packet, wherein the cryptographic data is larger than a single field, and wherein the cryptographic data is encapsulated within multiple fields associated with different network layers of the protocol stack;
wherein the multiple fields are received simultaneously by a receiving node that reconstructs an identity associated with the cryptographic data; and
wherein the multiple fields are encapsulated simultaneously into the data packet to ensure that the data packet can be routed through a network to reach the receiving node.
11. An apparatus for communicating cryptographic data through multiple network layers, comprising:
a receiving mechanism configured to receive the cryptographic data at a node;
a dividing mechanism configured to divide the cryptographic data into multiple pieces; and
an encapsulation mechanism configured to simultaneously encapsulate different pieces of the cryptographic data in fields associated with different network layers of a protocol stack in a data packet, wherein the cryptographic data is larger than a single field, and wherein the cryptographic data is encapsulated within multiple fields associated with different network layers of the protocol stack
wherein the multiple fields are received simultaneously by a receiving node that reconstructs an identity associated with the cryptographic data; and
wherein the multiple fields are encapsulated simultaneously into the data packet to ensure that the data packet can be routed through a network to reach the receiving node.
35. A computer system for verifying a data packet containing cryptographic data, comprising:
a central processing unit;
a semiconductor memory;
a receiving mechanism configured to receive the data packet;
an extracting mechanism configured to extract pieces of cryptographic data from fields associated with different network layers of a protocol stack within the data packet, wherein the cryptographic data is larger than a single field, and wherein the cryptographic data is simultaneously encapsulated within multiple fields; and
a verification mechanism configured to confirm that each piece of extracted cryptographic data matches with a corresponding portion of a piece of previously obtained cryptographic data;
wherein the multiple fields are received simultaneously to reconstruct an identity associated with the cryptographic data; and
wherein the multiple fields are simultaneously encapsulated into the data packet by a sending node to ensure that the data packet can be routed through a network to reach the receiving mechanism.
21. A computer system for communicating cryptographic data through multiple network layers, comprising:
a central processing unit;
a semiconductor memory;
a receiving mechanism configured to receive the cryptographic data at a node;
a dividing mechanism configured to divide the cryptographic data into multiple pieces; and
an encapsulation mechanism configured to simultaneously encapsulate different pieces of the cryptographic data in fields associated with different network layers of a protocol stack in a data packet, wherein the cryptographic data is larger than a single field, and wherein the cryptographic data is encapsulated within multiple fields associated with different network layers of the protocol stack;
wherein the multiple fields are received simultaneously by a receiving node that reconstructs an identity associated with the cryptographic data; and
wherein the multiple fields are encapsulated simultaneously into the data packet to ensure that the data packet can be routed through a network to reach the receiving node.
2. The method of
4. The method of
5. The method of
6. The method of
the local-id is comprised of the least-significant 128 bits of the output of the non-reversible function; and wherein
the host address is comprised of the IPv6 address.
7. The method of
8. The method of
9. The method of
10. The method of
12. The apparatus of
13. The apparatus of
14. The apparatus of
15. The apparatus of
16. The apparatus of
the local-id is comprised of the least-significant 128 bits of the output of the non-reversible function; and wherein
the host address is comprised of the IPv6 address.
17. The apparatus of
18. The apparatus of
19. The apparatus of
20. The apparatus of
22. The computer system of
23. The computer system of
24. The computer system of
25. The computer system of
26. The computer system of
the local-id is comprised of the least-significant 128 bits of the output of the non-reversible function; and wherein
the host address is comprised of the IPv6 address.
27. The computer system of
28. The computer system of
29. The computer system of
30. The computer system of
32. The method of
34. The apparatus of
36. The computer system of
|
|||||||||||||||||||||||||
1. Field of the Invention
The present invention relates to techniques for heightening security in communication protocols. More specifically, the present invention relates to a method and an apparatus for increasing network security by encapsulating cryptographic information across different network layers.
2. Related Art
The explosive growth of the Internet has led to a proliferation of networked devices over the past few years. Due to a large increase in the number of networked devices, the Internet Protocol version 4 (IPv4) address space, which is based on a 32-bit long address format, will soon run out of usable addresses. To solve this problem, Internet Protocol version 6 (IPv6) was proposed. IPv6 defines a 128-bit long address format, which is believed to provide a sufficient number of addresses to accommodate all networked devices. These networked devices can include cell phones, personal data assistants (PDAs), and other computing devices.
Unfortunately, when IPv6 was designed many years ago, it was difficult to foresee the wide deployment of wireless networks that are being used today. Hence, the IPv6 mechanisms that manage local links were designed with physically protected, trustworthy links in mind. Today, people are planning to use IPv6 on public wireless networks, such as Wireless LANs (WLANs) in airports, hotels, etc. In such networks, even though an actual link may be somewhat protected with layer two (data link layer) authentication, access control, and encryption, some of the nodes on the link could still be untrustworthy. Furthermore, it is easy to set up a non-authentic WLAN base station that can be used to launch various types of attacks, such as access stealing, Denial-of-Service (DoS) attacks, and traffic-snooping attacks.
To address these security problems in IPv6, a Cryptographically Generated Address (CGA) can be used. In essence, a CGA allows a node to use a short but secure expression of its public key (for example, a part of a secure hash of the public key) as part of its IPv6 address. This CGA mechanism actually allows a node to prove that it has the authorization to use a particular address. This simple but powerful concept has far-ranging implications and applications to network security, reaching beyond IPv6 networks.
A similar concept is that of a “Hash Based Address” (HBA). It also uses a secure hash (e.g., SHA-1); but instead of a public key, the input to the secure hash function is a static identifier. Accordingly, an HBA alone cannot prove that its owner is the sole entity authorized to perform certain operations on the address. Nevertheless, they do have the non-reversible property of the secure hash function. Hence, they can be used to prove that an HBA is a special type of address, one that is derived securely from certain (perhaps public) parameters. This property of safely distinguishing addresses, between those that have the HBA property and those that do not, is quite useful to prevent certain types of attacks.
Both the CGA and HBA proposals define ways to derive IPv6 addresses. However, both of the above suffer from the limitation that an IPv6 address (more specifically, the interface-identifier part of an IPv6 address) leaves only 62 bits available for the hash value. In order to derive the security properties of CGA/HBA schemes, enough bits are required so that the uniqueness properties of the secure hash are maintained. The secure hash function SHA-1 produces 160 bits, but with the limitation of IPv6 addresses (and other CGA/HBA applications), the output must be truncated and not all 160 bits can be used.
Nevertheless, it is generally acknowledged that 128 bits and even fewer bits (approximately 100 bits) are more than enough for protection against attackers trying to find collisions on the secure hash by brutal force.
However, in the case of CGA/HBA, people increasingly question whether 62 bits are enough.
There have been some efforts to work within the 62-bit limitation by trading off increased protection with increased work load when generating the addresses. This is not nearly as practical as being able to keep more bits from the output of the secure hash function.
Hence, what is needed is a method and an apparatus that allows more bits to be used with the CGA and HBA techniques.
One embodiment of the present invention provides a system that communicates cryptographic data through multiple network layers. During operation, the system receives the cryptographic data and divides the cryptographic data into multiple pieces. The system then encapsulates different pieces of the cryptographic data into fields associated with different network layers in a data packet, whereby an item of cryptographic data that is too large to be communicated in a single field can be communicated through multiple fields associated with different network layers.
In a variation of this embodiment, receiving the cryptographic data involves performing a non-reversible function on input data to produce the cryptographic data.
In a further variation, the input data includes a public key associated with the node.
In a further variation, the input data includes a static identifier associated with the node.
In a further variation, an IPv6 address field of the data packet is comprised of a 64-bit prefix followed by the most-significant 64 bits of the output of the non-reversible function, wherein a universal/local bit and an individual/group bit of the IPv6 address are both set to “0”.
In a further variation, an SSH public-key fingerprint field of the data packet is comprised of the least-significant 128 bits of the output of the non-reversible function.
In a further variation, a MAC address field of the data packet is comprised of the least-significant 64 bits of the output of the non-reversible function.
In a further variation, a JXTA Peer-ID field of the data packet is comprised of the least-significant 128 bits of the output of the non-reversible function.
In a further variation, a JXTA Group-ID field of the data packet is comprised of the least-significant 128 bits of the output of the non-reversible function.
In a further variation, a SIP Call-ID field of the data packet is comprised of a local-id and a host address, wherein the local-id is comprised of the least-significant 128 bits of the output of the non-reversible function; and wherein the host address is comprised of the IPv6 address.
One embodiment of the present invention provides a system that verifies a data packet containing cryptographic data. Upon receiving the data packet, the system extracts pieces of cryptographic data from fields associated with different network layers within the data packet. The system then verifies that each piece of extracted cryptographic data matches with a corresponding portion of a piece of previously obtained cryptographic data.
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
ISO/OSI Network Layer Model
Crypto-Based Identifier
One embodiment of the present invention distributes CBID 203 across multiple fields in multiple layers of the protocol stack. Another embodiment uses two fields in two layers, but there is nothing preventing one from encapsulating CBID bits in more than two layers.
Each address or identifier in a particular layer that one wishes to use to encapsulate a portion of the CBID can be initialized as follows: the address or identifier contains a truncated sequence of bits of CBID 203, wherein the actual number of included CBID bits is determined by how many bits are available in the corresponding address or identifier of a specific layer (e.g., Media Access (MAC) address, IP address, etc). Thus, portions of a single CBID can be embedded in fields associated with different layers of the OSI reference model.
The hash of public-key certificate 201 can be obtained through a SHA-1 hash function with an output of 160 bits: CBID=SHA-1(PK), wherein PK represents the public-key certificate. If more than 160 bits are desired to be encapsulated in several fields associated with different layers, these bits can be obtained by performing the hash function multiple times to produce multiple sets of 160 bits; whereby the input to the first hash function is the public-key certificate, the input to the second hash function is the public-key certificate concatenated by one “1” bit, the input to the third hash function is the public-key certificate concatenated by two “1” bits, and so on.
The above mechanism constitutes a “CLE” (Cryptographic Layering Enforcement) because a holder of a public key is required to use a number of verifiable identifiers and/or addresses corresponding to different OSI layers. The CBID binds together several vertically stacked (but not necessarily adjacent) layers. Because of the verifiability property of CBID's, and because a CBID is encapsulated across multiple layers, one is able to verify identifiers in multiple layers by checking the portions of CBID in these layers against the hash result of the sending node's public key. Moreover, this verifiability can be used to bootstrap a security association between two nodes, thus protecting a node from man-in-the-middle attacks on a Diffie-Hellman exchange.
Possible applications of CLE are tailored to a given subset of the different OSI layers. Such examples include: IPv6 address (network layer) and Secure Shell (SSH) public-key fingerprint (application layer), IPv6 address and MAC address (data link layer), IPv6 address and Session Initiation Protocol (SIP) Call-ID (application layer), and IPv6 address and JXTA Peer-ID or Group-ID (application layer).
CLE Examples
The other part of CLE, an SSH public-key fingerprint 302, is comprised of the least-significant 128 bits of CBID 203.
The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.
Montenegro, Gabriel E., Laganier, Julien H.
| Patent | Priority | Assignee | Title |
| 10951423, | Mar 29 2016 | KONINKLIJKE PHILIPS N V | System and method for distribution of identity based key material and certificate |
| Patent | Priority | Assignee | Title |
| 6101543, | Oct 25 1996 | Hewlett Packard Enterprise Development LP | Pseudo network adapter for frame capture, encapsulation and encryption |
| 6804776, | Sep 21 1999 | Cisco Technology, Inc. | Method for universal transport encapsulation for Internet Protocol network communications |
| 20040008845, | |||
| 20040010683, | |||
| 20040128376, | |||
| 20040193875, | |||
| 20040193876, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Sep 26 2003 | MONTENEGRO, GABRIEL E | Sun Microsystems, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014564 | /0975 | |
| Sep 26 2003 | LAGANIER, JULIEN H | Sun Microsystems, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 014564 | /0975 | |
| Sep 29 2003 | Sun Microsystems, Inc. | (assignment on the face of the patent) | / | |||
| Feb 12 2010 | ORACLE USA, INC | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037303 | /0336 | |
| Feb 12 2010 | Sun Microsystems, Inc | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037303 | /0336 | |
| Feb 12 2010 | Oracle America, Inc | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037303 | /0336 |
| Date | Maintenance Fee Events |
| Mar 18 2009 | ASPN: Payor Number Assigned. |
| Mar 18 2009 | RMPN: Payer Number De-assigned. |
| Sep 21 2011 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Dec 30 2015 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Jan 03 2020 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Jul 15 2011 | 4 years fee payment window open |
| Jan 15 2012 | 6 months grace period start (w surcharge) |
| Jul 15 2012 | patent expiry (for year 4) |
| Jul 15 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jul 15 2015 | 8 years fee payment window open |
| Jan 15 2016 | 6 months grace period start (w surcharge) |
| Jul 15 2016 | patent expiry (for year 8) |
| Jul 15 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jul 15 2019 | 12 years fee payment window open |
| Jan 15 2020 | 6 months grace period start (w surcharge) |
| Jul 15 2020 | patent expiry (for year 12) |
| Jul 15 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |