Patent Grant
8600059
This disclosure relates in general to short message service (SMS) and, but not by way of limitation, to encryption of SMS.
SMS is used to pass private messages and control messages. Some cellular phones systems encrypt all communication between the base station and mobile handsets. This encryption has been hacked on some phone systems and does not provide adequate security for some situations. Control messages sent over SMS can be particularly sensitive. Phone features, personal information, keys, etc. can be sent in control messages.
SMS messages are very small being generally limited to 1120 bits and use a variety of character sets. There are 160 characters in a SMS message for 7 bit character sets and 140 characters for an 8 bit character set. Encrypting small messages with keys that can often be larger than the SMS, produces weak protection and high overhead. Many of the available characters in the SMS message are lost in support of conventional encryption.
In one embodiment, the present disclosure provides a wireless phone system and methods performed thereon for cryptographically processing SMS messages. A cryptographic pad is used to replace characters in a payload of a SMS message with coded characters. The cryptographic pad is used by the receiver of the SMS message to decode it. The cryptographic pad is one of two or more possible cryptographic pads stored in the receiver. In one embodiment, the two or more possible cryptographic pads are sent as a key where a particular cryptographic pad is referenced in the key using an index.
In another embodiment, a cellular telephone encryption system for protecting messages for a handset is disclosed. The cellular telephone encryption system includes a key, an index, a cryptographic algorithm, and a wireless transceiver. The key is larger than the messages, where the key is arranged in a circular buffer. The index indicates a reference point for a cryptographic pad, which is a subset of the key. The cryptographic algorithm cryptographically processes a message as a function of the cryptographic pad. The wireless transceiver that sends or receives the message.
In yet another embodiment, a method for cryptographically processing short message service (SMS) messages of a handset is disclosed. After loading a key, an index within the key is determined. As a function of a cryptographic pad located by the index, a replacement character is determined. A character in the payload of the SMS message is replaced with the replacement character.
In still another embodiment, a method for cryptographically processing short message service (SMS) messages of a handset. A value that identifies a cryptographic pad is provided from a plurality of cryptographic pads that are use to cryptographically process a SMS message. The chosen cryptographic pad is loaded. A replacement character, that is a function of the cryptographic pad identified by the value, is determined. A character in the payload of the SMS message is replaced with the replacement character.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating various embodiments, are intended for purposes of illustration only and are not intended to necessarily limit the scope of the disclosure.
The present disclosure is described in conjunction with the appended figures:
In the appended figures, similar components and/or features may have the same reference label. Where the reference label is used in the specification, the description is applicable to any one of the similar components having the same reference label.
The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.
In one embodiment, the present disclosure provides the ability to pass encrypted XML, or other printable characters, between the handset and a server in a wireless phone system. The short message service (SMS) message length is 170 characters or less. The SMS uses Binary Runtime Environment for Wireless (BREW®) directed SMS, which uses 16 characters for its message header. This leaves only 144 characters for the payload to pass useful information to or from the handset. The BREW® implementation of standard encryption schemes like AES and TripleDES requires conversion to base64 and a trailing empty block, which leaves only 89 bytes for useful information for the payload in each SMS message. Other embodiments need not use the same protocol as BREW®.
Rather than use a binary, block oriented encryption scheme, a stream cipher is used: each printable character is encrypted by converting it to some other printable character. There are 95 printable characters—ASCII 32 (i.e., space) through ASCII 126 (i.e., tilde) used as possible characters in the SMS payload, but other embodiments could use 64 or 128 characters. Another embodiment uses the GSM default alphabet which is a 7-bit character set defined in the ETSI GSM Phase 2+ Technical Specification 03.38. Each handset has its own binary key between 256 and 4096 bytes, but other embodiments could have keys of any size (e.g., 1, 8, 16, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384 bytes, or any power of 2 or other integer). Some embodiments could have different sized binary keys for different handsets in the wireless communication system. The binary key is unique for each handset in one embodiment. In some embodiments, groups of handsets may have the same binary key. The binary key is sent to the handset at provisioning and updated via hypertext transfer protocol secure (HTTPS) or some other encrypted channel. Other embodiments could update the binary key using private or public key cryptography. The binary key can be updated when the handset in the field has been corrupted or compromised. Some embodiments change out the binary key periodically. The binary key includes random or pseudorandom values generated by a key generation server in the network controller or elsewhere in the wireless phone system.
The encryption algorithm itself is stored on the handset and therefore available to anyone who buys a phone and is able to break in and read its embedded software. Security lies in the uniqueness of the binary key for each handset or group of handsets. Different handsets in the wireless phone system can have keys of different lengths. The binary key is protected on the handset and inaccessible to the user. Where tampering of the handset is detected, the binary key can be erased and/or updated. The embedded software and/or state machines implementing the encryption algorithm can be secure and/or tamper resistant. The binary key can be held in memory in encrypted form only being decrypted prior to use in cryptoprocessing of SMS messages. The encryption algorithm can be implemented in software and/or hardware. One embodiment holds the cryptoalgorithm and binary key in the same semiconductor chip where the binary key and is not accessible outside the semiconductor chip in unencrypted form.
In one embodiment, the 95 member character set is arranged in a circular list. Distances may be greater than 95 and rotate a number of times through the circular list before finding the replacement character. The circular list may be sequentially, randomly or pseudorandomly arranged with both server and handset knowing the arrangement in the circular list. To encrypt a SMS message, each character in the plaintext message is replaced with the character that is some computed distance forward in the circular list. To decrypt a message, run through each character in the encrypted message and replace it with the character that is the same computed distance backward in the circular list.
The binary key is an array of bytes, which are random or pseudorandom values between 0 and 255, but other embodiments could use larger or smaller values for each group of bits arranged in the array. The binary key is generated away from the handset in the wireless phone system and is known to the handset and a crypto controller to allow cryptographic communications between them. Other embodiments could use public keying to create the binary key.
In order to use the random data in the binary key in a first embodiment, the distance computation between characters in the circular list includes multiple hops through the key data, using the key value at each hop as input into the next hop distance. Except for the first character, the distance computation will also take the previous characters distance as input. Some embodiments do not use previous distance calculations in distance computations.
In order to vary the first characters distance computation, two random characters are generated at encryption time and put, in plaintext, at the front of the SMS message by the handset or server sending the SMS message. These two values (a and b) and the length of the message (c) are used to compute a set of nine offsets: a*b+a, a*b+b, a*b+c, a*c+a, a*c+b, a*c+c, b*c+a, b*c+b, b*c+c. Another embodiment mixes the offset equations randomly or pseudo randomly for different handsets. This helps make references to the binary key that are spread across its entire length.
The distance computation starts in a first embodiment with the previous character distance (zero for the first character) and loops though the 9 offsets using the sum of the offset and the key value at the previous hop as an index into the key.
Given the following 256 byte binary key (expressed in base64 hex):
In order to use all of the random data in the binary key in a second embodiment, the distance computation between characters in the circular list includes multiple hops through the key data, using the key value at each hop as input into the next hop distance as well as an block offset based on the message length to insure the entire key is utilized. Except for the first character, the distance computation will also take the previous characters distance as input. Some embodiments do not use previous distance calculations in distance computations.
In order to vary the first characters distance computation, two random characters are generated at encryption time and put, in plaintext, at the front of the SMS message by the handset or server sending the SMS message. These two values (a and b) and the length of the message (c) are used to compute a set of nine offsets: a*b+a, a*b+b, a*b+c, a*c+a, a*c+b, a*c+c, b*c+a, b*c+b, b*c+c. Another embodiment mixes the offset equations randomly or pseudo randomly for different handsets. This helps make references to the binary key that are spread across its entire length.
To insure that the entire key is utilized in the second embodiment, a block offset is calculated equal to the length of the key divided by the length of the message.
In the second embodiment, the distance computation starts with the previous character distance (zero for the first character) and loops though the 9 offsets using the sum of the offset and the key value at the previous hop as an index into the key.
Given the following 256 byte binary key (expressed in base64 hex):
Other embodiments could arrange the key in a circular list and just send a randomly-generated index that specifies where in the circular list to gather the cryptographic pad to use for a particular message. The binary key is many times larger than a cryptographic pad needed for a SMS message so in essence the binary key holds a number of cryptographic pads. Another embodiment could send a number of cryptographic pads that are selectable by the index. Each SMS message will use these cryptographic pads in an unpredictable way as specified by the index.
Referring initially to
The air interface in a wireless phone system 100 can be used to protect all communication or subsets of the communication. In some cases, this cryptographic protection has been compromised. Embodiments layer on top of the air interface cryptographic protection providing a per message/communication protection. Additionally, some may want greater protection of certain messaging. There could even be multiple levels of cryptographic protection. For example, some messages could use a particular index only once to limit a cryptographic pad to a single use, which is virtually uncrackable. A lesser amount of protection is available when using an index and cryptographic pad multiple times. The level of protection could be scaled from strong to weak, by the number of times a cryptographic pad can be reused.
With reference to
A handset 105 is provisioned with a key before reaching the customer. The key could alternatively be created when the customer activates the handset 105. Periodically, the key could be exchanged with a new key. If the crypto controller 204 determines that messages are not being decrypted properly at the handset 105 or if messages from the handset 105 are indecipherable, a new key will be formulated. A new key is produced by the key generation server 228 randomly. The handset 105 is given a HTTPS link to request over the data channel 224. The new key is delivered to the handset 105 through the HTTPS interface 216.
The crypto controller 204 manages key creation, key delivery and message cryptofunctions. Command/control messages use the SMS channel 220 and SMS protocol. The crypto controller 204 sends and receives SMS messages using the SMS transceiver 212. In this embodiment, the MEID is used to retrieve the key for a particular handset from the key store 208. The crypto controller 204 uses the crypto algorithm along with the key and an index to decrypt or encrypt the SMS message. The sender of the message randomly generates the index value to indicate where in the key to find the cryptographic pad being used for the particular message.
Although this embodiment uses cryptography to protect SMS messages, it is to be understood that there are other uses for the technology. E-mail, tweets, status updates, location information, social network updates, or any other messages communicated with handsets 105 could be protected cryptographically. Where there are multiple cryptographic pads and a selection on a per message or communication basis, this algorithm provides strong protection of that communication.
Referring next to
The overhead 308 in this embodiment includes the SMS header 304, which is the header information defined by the SMS protocol. The control header 312 could be a BREW® directed SMS header, but not necessarily so. The control header 312 indicates that the SMS message is encrypted or not. It could be one bit or byte in various embodiments. The key index 316 holds the value used to determine which cryptographic pad to use. In one embodiment, the index is an offset that is used to determine the characters to use from the key when arranged in a circular buffer. In this embodiment, the key index field holds two bytes used as the index.
The payload 320 in plaintext form is represented in a XML or binary data structure. Where a given data structure cannot be contained in a single message, the control header 312 can be used to denote which part of a multipart message was received. If one SMS message of the multipart data structure is lost, it can be requested before reconstituting the entire data structure. The SMS header 304 includes the senders phone number or 5 digit source identifier. Control/command messages originate from a known source so if the phone number or 5 digit source identifier doesn't match what is expected, the command/control information is ignored.
With reference to
At some point, a new key may be needed. The key could expire, be compromised, be corrupted or hacked to precipitate changing the key. On occasion, a test message could be sent to the handset 105 in encrypted form triggering a response. In some embodiments, the response would include a code sent in the query such that its absence in the response would show an error at the handset 105. If the crypto-processing is compromised on the handset 105, the response would presumably not occur or be improper.
The crypto controller 204 would send a SMS message without encryption telling the handset 105 to initiate a secure connection to retrieve a new key in block 420. In this embodiment, a HTTPS universal resource locator (URL) link is sent to the handset 105. In block 404, a new key is randomly generated for the handset 105 and stored by MEID in block 412. The handset 105 requests the URL over a secure connection, which is delivered in block 424. With a new key, normal operation begins again in block 416.
Referring next to
In block 508, the index is randomly determined. The index defines which characters from the key will comprise the cryptographic pad for a given message. The crypto controller 204 replaces all the payload characters with encrypted characters using the crypto algorithm and cryptographic pad in block 512. The index is placed in the key index field 316 of the message along with modifying any bit(s) in the control header 312 to signal that the message has an encrypted payload in block 516. The SMS message is delivered over the SMS channel 220 wirelessly in block 520. For command/control messages, the handset 105 only accepts them when sent from a particular sender indicated by a phone number or 5 digit code. A command/control message from another number would fail authentication and not be processed.
In block 524, the handset 105 retrieves the index from the SMS message and retrieves the key from memory. The payload is decrypted with the stream cipher algorithm with the cryptographic pad gathered from the key using the index in block 528. The information in the payload of the message is processed in block 532. For command or control messages, the payload is contained in an XML format. Where the XML datastructure cannot be contained in a single message, it is sent using a number of messages and reformulated by the handset 105. Other embodiments could use a binary format for the payload rather than XML.
While the principles of the disclosure have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the disclosure.
This application is a continuation of pending U.S. patent application Ser. No. 13/149,612 filed on May 31, 2011 which claims the benefit of and is a non-provisional of U.S. Provisional Application Ser. No. 61/350,360 filed on Jun. 1, 2010, which are hereby expressly incorporated by reference in their entirety for all purposes.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5664017 | Gressel et al. | Sep 1997 | A |
| 5909491 | Luo | Jun 1999 | A |
| 6097961 | Alanara et al. | Aug 2000 | A |
| 6185417 | Pyorala | Feb 2001 | B1 |
| 6324287 | Angert | Nov 2001 | B1 |
| 6480096 | Gutman et al. | Nov 2002 | B1 |
| 6498936 | Raith | Dec 2002 | B1 |
| 7076657 | Koukoulidis et al. | Jul 2006 | B2 |
| 7366842 | Acocella et al. | Apr 2008 | B1 |
| 7424302 | Carpenter | Sep 2008 | B2 |
| 7546118 | Camp, Jr. | Jun 2009 | B2 |
| 7548757 | Major | Jun 2009 | B2 |
| 7565546 | Candelore | Jul 2009 | B2 |
| 7603112 | Huomo et al. | Oct 2009 | B2 |
| 7694128 | Judge et al. | Apr 2010 | B2 |
| 8050405 | Camp et al. | Nov 2011 | B2 |
| 20020035687 | Skantze | Mar 2002 | A1 |
| 20020131598 | Chiu | Sep 2002 | A1 |
| 20020177454 | Karri et al. | Nov 2002 | A1 |
| 20020191795 | Wills | Dec 2002 | A1 |
| 20030026429 | Hammersmith | Feb 2003 | A1 |
| 20030044016 | Nocham et al. | Mar 2003 | A1 |
| 20030072450 | Maggenti | Apr 2003 | A1 |
| 20030078058 | Vatanen et al. | Apr 2003 | A1 |
| 20040034693 | Agarwal | Feb 2004 | A1 |
| 20040106418 | Cini et al. | Jun 2004 | A1 |
| 20040117623 | Kalogridis et al. | Jun 2004 | A1 |
| 20040142709 | Coskun et al. | Jul 2004 | A1 |
| 20040203957 | George | Oct 2004 | A1 |
| 20040235503 | Koponen et al. | Nov 2004 | A1 |
| 20050031124 | Jain et al. | Feb 2005 | A1 |
| 20050048971 | Findikli et al. | Mar 2005 | A1 |
| 20050114664 | Davin | May 2005 | A1 |
| 20050135622 | Fors et al. | Jun 2005 | A1 |
| 20050226420 | Makela et al. | Oct 2005 | A1 |
| 20050232422 | Lin et al. | Oct 2005 | A1 |
| 20060177065 | Halbert | Aug 2006 | A1 |
| 20060204011 | Adams et al. | Sep 2006 | A1 |
| 20060234731 | Taylor et al. | Oct 2006 | A1 |
| 20070073627 | Richards | Mar 2007 | A1 |
| 20070074276 | Harrison et al. | Mar 2007 | A1 |
| 20070087765 | Richardson et al. | Apr 2007 | A1 |
| 20070172066 | Davin | Jul 2007 | A1 |
| 20070258584 | Brown et al. | Nov 2007 | A1 |
| 20080005024 | Kirkwood | Jan 2008 | A1 |
| 20080031459 | Voltz et al. | Feb 2008 | A1 |
| 20080085728 | Reding et al. | Apr 2008 | A1 |
| 20080089519 | Ekberg | Apr 2008 | A1 |
| 20080170689 | Boubion et al. | Jul 2008 | A1 |
| 20080208886 | Zhang | Aug 2008 | A1 |
| 20080268882 | Moloney | Oct 2008 | A1 |
| 20080300000 | Carpenter | Dec 2008 | A1 |
| 20080311935 | Tysowski | Dec 2008 | A1 |
| 20090060198 | Little | Mar 2009 | A1 |
| 20090061912 | Brown et al. | Mar 2009 | A1 |
| 20090143087 | Minborg et al. | Jun 2009 | A1 |
| 20090185677 | Bugbee | Jul 2009 | A1 |
| 20090198997 | Yeap et al. | Aug 2009 | A1 |
| 20090215476 | Tysowski | Aug 2009 | A1 |
| 20090227274 | Adler et al. | Sep 2009 | A1 |
| 20090239557 | Kadakia et al. | Sep 2009 | A1 |
| 20090265552 | Moshir et al. | Oct 2009 | A1 |
| 20090325615 | McKay et al. | Dec 2009 | A1 |
| 20100020972 | Baugher et al. | Jan 2010 | A1 |
| 20100041424 | Osborn | Feb 2010 | A1 |
| 20100069097 | Chin et al. | Mar 2010 | A1 |
| 20100087212 | Shi et al. | Apr 2010 | A1 |
| 20100159962 | Cai et al. | Jun 2010 | A1 |
| 20100248757 | Baek | Sep 2010 | A1 |
| 20100298014 | Kamphuis | Nov 2010 | A1 |
| 20110039587 | Madhavan et al. | Feb 2011 | A1 |
| 20110055546 | Klassen et al. | Mar 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 2005104422 | Nov 2005 | WO |
| Entry |
|---|
| “One Time Pad” from http://users.telenet.be/d.rijmenants/en/onetimepad.htm. pp. 1-12. Retrieved Mar. 23, 2012. |
| Number | Date | Country | |
|---|---|---|---|
| 20120033814 A1 | Feb 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61350360 | Jun 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13149612 | May 2011 | US |
| Child | 13276225 | US |
