Patent Application
20060041741
The invention relates generally to a system and method for decryption of encrypted IP packets. More specifically, the invention provides a method and system for IP level conditional access decryption without an application supplying encryption details for the decryption.
TCP/IP (Transmission Control Protocol/Internet Protocol) is the basic communication language or protocol of the Internet and may be used as a communications protocol in a private network, either an intranet or an extranet. TCP/IP is a networking protocol that allows various computers with differing hardware and software architectures within a plurality of networks to communicate with each other. TCP/IP is generally described by a protocol stack model that describes various functions of the stack into layers. As described below,
TCP/IP is often described using four functional layers, although the actual Transmission Control protocol and Internet Protocol subsets are generally run at two of the four layers. As shown in
Transmission Control Protocol (TCP) assembles a message or data into smaller packets that are transmitted over a network, such as the Internet, and eventually received by a TCP layer in a destination computer that reassembles the packets into the original message or data. Internet Protocol (IP) addresses each packet so that the packets get to the correct destination. Intermediate computers on the network check the IP address to determine where to forward the package. Each packet from an original message may be routed differently to the destination computer, but eventually they are reassembled at the same destination.
Transport layer 103 includes the TCP subset. Transport layer 103 maintains protocols for end-to-end connectivity and data integrity. Transport layer 103 provides error control capability. Transport layer 103 provides detection of and recover from lost, duplicated, or corrupted packets of data. In the transport layer 103, data from the application layer 101 is divided into packets each with a sequence number that indicates the order of the packets in a block. As each packet is received by the transport layer 103 of a destination computer, the destination transport layer 103 examines the packet and, when a complete sequence of packets are received, sends an acknowledgement (ACK) signal to the source computer indicating the next expected sequence number. Transport layer 103 includes TCP and User Datagram Protocol (UDP). UDP is used instead of TCP for special purposes. Other protocols may be maintained in the transport layer 103. Transport layer 103 is also responsible for moving data between the application layer 101 and the internetwork layer 105.
Internetwork layer 105 includes the IP subset. Internetwork layer 105 maintains protocols for routing messages or data through internetworks. Internetwork layer 105 attempts to deliver every packet of data but does not retransmit lost or corrupted packets. Gateways and routers are responsible for routing messages or data between networks. The internetwork layer 105 provides a datagram network service. Datagrams are packets of information that comprise a header, data, and a trailer. The header contains information that the network needs to route the packets. Examples of header information include a destination address for the packet, a source address for the packet, and security labels. The trailer often contains a checksum to ensure that the data has not been manipulated in any improper or unauthorized manner while in transit. Another protocol that may be maintained in the internetwork layer 105 includes the Internet Control Message Protocol (ICMP). Internetwork layer 105 is also responsible for moving data between the transport layer 103 and the network interface layer 107.
Network interface layer 107 maintains the protocols for managing the exchange of data between a device and the network to which the device is coupled and for routing data between devices on the same network. Network interface layer 107 encapsulates the IP datagrams into frames that are transmitted by the network and also maps the IP addresses to the physical addresses used by the network. Network interface layer 107 adds routing information to the data received from the internetwork layer 105. This routing information is added in the form of a header field.
Each layer in the protocol stack adds control information to ensure proper delivery. Control information may include the destination address, the source address, routing controls, security labels, and checksum data. Upon reaching each layer of the stack from the application layer 101 to the network interface layer 107, the layer treats the header, data, and trailer information received from the previous layer as data and adds its own header and trailer information to the data. When a protocol uses a header and trailer to package data from another protocol, the process is called encapsulation.
As described above, an application layer 101 may include functions directed to data encryption and decryption. Application layer 101 may be included within an IPsec stack. An IPsec stack is a protocol stack including a collection of IP measures. In particular, IPsec supports authentication through a header field which verifies the validity of the originating address in the header field of every packet of a packet stream. An encapsulating security payload (ESP) header field encrypts the entire datagram based upon the encryption parameters/properties. Securing IP packets using IPsec requires a destination host computer to decrypt the received packets before being able to use the content of the packets. The decryption is implemented using a key or a set of keys and/or using some additional parameters/properties. The keys and the parameters/properties are supplied to the TCP/IP stack/architecture of the system for correct decryption of encrypted IP packets. Encryption parameters/properties are supplied by an application to an IPsec stack.
If applications must supply encryption information to the IPsec stack, the applications are more complex. A need exists to be able to keep applications using TCP/IP services simple and unaware of possible encryption of the services. A need exists for the surrounding system to be able to provide services in a decrypted form to the applications with any interface from the point of view of the application appearing as if the service is unencrypted.
According to aspects of the invention, a request from an application is received for IP packets associated with a first IP address/port pair. The port may be a TCP port and in one embodiment of the present invention the port is a UDP port. IP packets associated with a different IP address/port pair are also received. Decryption information is extracted from the IP packets associated with the different IP address/port pair and the IP packets associated with the first IP address/port pair, when received encrypted, are decrypted based upon the extracted decryption information. The decrypted IP packets associated with the first IP address/port pair are then transmitted to the application.
Another aspect of the invention provides a system for delivering decrypted IP packets. A TCP/IP stack is configured to receive requests for IP packets and to transmit IP packets. A packet receiver, in communication with the TCP/IP stack, is configured to receive IP packets and to transmit IP packets. An IPsec key manager, in communication with the TCP/IP stack and the packet receiver, is configured to coordinate extraction of decryption information from a first IP packet stream and transmission of the decryption information. A digital rights management component, in communication with the IPsec key manager, is configured to extract the decryption information, and an IPsec stack, in communication with the TCP/IP stack and the IPsec key manager, is configured to decrypt encrypted IP packets from a second at least partially encrypted IP packet stream based upon the decryption information. The decryption information may be independent of the application.
A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:
In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.
In accordance with aspects of the invention, a first IP address/port pair is associated with a different IP address/port pair and the key(s) and/or parameters/properties needed for decryption of the first encrypted IP data stream sent to the first IP address/port pair are sent to the different IP address/port pair. For example, a well-defined TCP port may be associated with every IP address. This well-defined port then is used as a destination port for the IPsec keys and/or parameters/properties for decrypting the packets sent to all other ports of the first IP address. The ports may be TCP or UDP type ports. In an alternative embodiment, the decryption parameters/properties and/or key(s) may be sent to the same port as the encrypted service, while the IP address of the host and destination devices are different.
TCP/IP stack architecture 300 includes an application 302 that makes the initial request to receive packets from a particular IP address/TCP port pair. An IP address/TCP port pair is described herein in a configuration of an IP address, followed by a colon, followed by the TCP port. For example, an example IP address/TCP port pair may be 168.198.0.1:80. As used herein, an IP address/TCP port pair is referred to as A:X and A:Y to designate an IP address A and two different TCP ports X and Y. Application 302 has a communication link to TCP/IP stack 304. TCP/IP stack 304 is shown in communication with a packet receiver 306 for requesting and receiving IP packets from designated IP address/TCP port pairs.
TCP/IP stack 304 also is shown in communication with an IPsec stack 312. IPsec stack 312 performs decryption on encrypted IP packets received from the TCP/IP stack 304. IPsec stack 312 also returns the decrypted IP packets to the TCP/IP stack 304 upon completing decryption of the IP packets.
Packet receiver 306 is shown in communication with an IPsec key manager 308. IPsec key manager 308 is configured to cause extraction of decryption key(s) and/or properties/parameters and to forward the decryption key(s) and/or properties/parameters to the IPsec stack 312. In accordance with at least one aspect of the present invention, IPsec key manger 308 may be included within the IPsec key manager 308 component. Decryption properties/parameters may include the decryption pattern, i.e., which bits of a packet to decrypt and which bits to not decrypt, the decryption technique, i.e., the algorithm used for decryption purposes, and/or other information. IPsec key manager 308 also is in communication with a digital rights management (DRM) element 310. DRM 310 manages all rights, not only the rights applicable to permissions over digital content. These rights include usage, copying authorization and/or restriction, editing rights, and transmission rights. DRM 310 provides the IPsec key(s) and decryption parameters/properties extracted from a different TCP port, independent of the application 302. In accordance with at least one aspect of the present invention, the DRM element can be an Open Mobile Alliance (OMA) DRM component such as OMA DRM 1.0 or OMA DRM 2.0. In accordance with at least one aspect of the present invention, DRM 310 functions may be included within the IPsec key manager 308 component.
Aspects of the invention fit into existing TCP/IP stack architectures that may require additional software modules outside the existing software modules. There is no restriction on any non-encrypted IP service and applications 302 are effectively unaware of any encryption in the IP level. Aspects of the invention may be used as part of a service encryption system, e.g., when using Internet Protocol Datacast (IPDC) in Digital Video Broadcasting (DVB), its variations such as DVB-Terrestrial (DVB-T), and also in DVB-Handheld (DVB-H). In addition, aspects of the present inventions may be used in other digital video and television systems such as the U.S. Advanced Television Systems Committee (ATSC) and Japanese Integrated Services Digital Broadcasting-Terrestrial (ISDB-T) and Digital Multimedia Broadcasting-Terrestrial (DMB-T).
The decryptor 360 receives the data from the IP address/port pair A:X. The data from the IP address/port pair A:X is at least partially encrypted data. Decryptor 360 decrypts the data from the IP address/port pair A:X based upon the decryption information received from the decryption information extractor. Decryptor 360 then outputs the data from the IP address/port pair A:X in an decrypted form. This decrypted data from the IP address/port pair A:X may be sent to an application that originally requested the data. From the perspective of the application, the data requested from IP address/port pair was never encrypted.
At step 408, the packet receiver signals an IPsec key manager for the need to decrypt IP packets for IP address/TCP port pair A:X. The IPsec key manager may be IPsec key manager 308. Upon receipt of the request from the packet receiver in step 408, the IPsec key manager sends a request to the TCP/IP stack for IP packets destined to IP address/TCP port pair A:Y at step 410. In accordance with at least one aspect of the present invention, key(s) and/or properties/parameters are maintained within a well-defined IP stream. The IPsec manager may be configured to look to a particular IP address/TCP port pair A:Y in order to obtain the necessary decryption information to decrypt the IP packets destined to IP address/TCP port pair A:X.
The process proceeds to step 412 where the TCP/IP stack signals the packet receiver for the need to receive IP packets destined to IP address/TCP port pair A:Y. IP address/TCP port pair A:Y may be a well-known IP address/port pair. At step 414, the TCP/IP stack receives the IP packets destined for IP address/TCP port pair A:Y from the packet receiver. The IPsec key manager receives the IP packets for IP address/TCP port pair A:Y at step 416. The process then continues at step 418 illustrated in
At step 418, the IPsec key manager provides the contents of the IP packets destined to IP address/TCP port pair A:Y to a digital rights management (DRM) element. The digital right management element may be DRM 310. At step 420, the DRM element receives the contents of the IP packets destined to IP address/TCP port pair A:Y and extracts IPsec key(s) and/or decryption properties/parameters for IP packets sent to IP address/TCP port pair A:X. The IPsec key manager forwards the IPsec key(s) and/or decryption properties/parameters for decryption of the IP packets destined to IP address/TCP port pair A:X to an IPsec stack at step 422. The IPsec stack may be IPsec stack 312.
The process proceeds to step 424 where the IPsec stack receives IP packets destined for IP address/TCP port pair A:X from the TCP/IP stack. Some or all of the received IP packets may be encrypted. Upon receipt of the IP packets from the TCP/IP stack, at step 426, the IPsec stack decrypts the encrypted IP packets using the key(s) and decryption properties/parameters received from the IPsec key manager in step 422. At step 428, the IPsec stack sends the decrypted IP packets to the TCP/IP stack, and at step 430, the decrypted IP packets destined for IP address/TCP port pair A:X are forwarded from the TCP/IP stack to the application. From the perspective of the application, a request for IP packets was requested and received without any indication that data was encrypted and/or decrypted in the process. Further, the application need not provide the encryption and/or decryption information used for obtaining the requested IP packets.
One or more aspects of the invention may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers, set top boxes, mobile terminals, or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.
