Systems and methods using one time pads during the exchange of cryptographic material

Abstract

A solution that enables the exchange of information in a secure manner over an insecure text messaging infrastructure provides part of the exchange as cryptographic material to be used to secure subsequent communications. The exchange of the cryptographic material is protected from malicious and nefarious parties. Systems and methods for the exchange of cryptographic material enable the parties involved in the exchange to have confidence that the material received was communicated from the originating party. Once the cryptographic material is successfully exchanged between cooperating peers, it can be used by smartphones, tablets, feature phones, or special purpose machine to machine devices for private communications, such as command and control, location services, etc. over insecure voice or data communication paths, such as SMS.

Description

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

N/A

FIELD

The technology herein relates to exchange of cryptographic material, and more particularly to methods and systems used to secure the exchange of cryptographic material between cooperating peers.

BACKGROUND AND SUMMARY

One of the many problems with the exchange of cryptographic material is ensuring its authenticity. To date, many systems have been devised to enable two peer devices to exchange credentials in an authenticate fashion. This includes the use of X.509 certificates that are associated with a certificate authority. Other methods such as a Short Authentication String (SAS) have been devised by the Pretty Good Privacy (PGP) efforts. Such traditional methods have shortcomings whether it be in terms of complexity or fragility against malicious attacks.

For example, suppose that two peer systems wish to securely exchange message-oriented data across unsecure voice and/or data communications paths. Based on the use of public key cryptography, the at least two peers exchange public keys in an authenticated manner. Traditionally this is done using additional infrastructure and/or at least one trusted third party (e.g., a certifying authority) that can vouch for the veracity of each of the public keys to prevent spoofing. This additional infrastructure or service can be cumbersome to setup and use, and can also be expensive to maintain.

To alleviate this burden, the exchange of cryptographic material can be enhanced by using a one time passcode or passphrase (OTP) that is minimally used to validate the authentication of the cryptographic material between cooperating peers. The OTP may also be used as a seed to encipher the exchange, obscuring the cryptographic material from potential nefarious or malicious parties. Furthermore, the OTP can be end-user friendly, allowing input through standard user input methods (i.e. keyboard, touchscreen, gestures, etc.).

For increased privacy, it is desirable for the OTP to be agreed upon between the cooperating peers out of band of the cryptographic material exchange. In one exemplary non-limiting example, voice communications (either over a network or in person) may be used to securely exchange the one time pad. Using this a priori knowledge of the OTP, it is then applied to authenticating and/or deciphering the cryptographic material that can be used as the basis for subsequent communications.

Consider the following non-limiting use case where two individuals would like to exchange cryptographic material used to secure short message service (SMS) communications with an application such as ProtectedSMS. In one common example scenario, two individuals are standing near one another and exchange contact information such as name, phone number, etc. During their exchange, one party suggests an OTP to use for establishing a secure relationship. As indicated before, this can be in the form of numbers, letters, passwords, gestures on a touch screen, etc. At this point the users enter the OTP into the application for use during the Protected SMS Contact Registration Exchange (CRE). Prior to the initiating peer sending out the registration request, the OTP is used as an authentication key for a one-way keyed-hash algorithm such as SHA256-HMAC and/or used as or to generate a cryptographic key that can be used to encipher the message. Upon the processing of the registration request message by the receiving peer, the Protected SMS application will use the OTP to decipher and/or authenticate the registration request. If the process correctly deciphers and/or authenticates the request, the peer knows that the request was valid from the initiating party. If not, an error status is returned to the user to indicate that either the request may have been corrupted in transit or a nefarious party tried to mount was is commonly referred to as a man-in-the-middle (MITM) attack. If the message was valid, the OTP can then be used to authenticate and/or cipher the registration response message that is sent back to the initiating peer. At this point, if the registration exchange has successfully completed, each peer system can be confident in the veracity of the cryptographic material exchanged.

Integrating the OTP functionality into the initial exchange of cryptographic material between two systems further increases the security of the exchange. If the OTP is truly random and kept secret between the two parties exchanging the cryptographic material, the validity of the material can be assured. As a by-product of this process, attempts to thwart the exchange can also be more easily detected.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages will be better and more completely understood by referring to the following detailed description of exemplary non-limiting illustrative embodiments in conjunction with the drawings of which:

FIG. 1 schematically illustrates an exemplary illustrative non-limiting prior art conventional text or other messaging communication system;

FIG. 1A shows non-exhaustive examples of end user or other devices that can be employed;

FIG. 2 shows multiple vulnerabilities present in the FIG. 1 prior art system;

FIG. 3 shows one way that end-to-end security can be provided irrespective of the communications medium and without requiring any intermediary device for secure transmissions;

FIGS. 4A, 4B show an exemplary illustrative non-limiting protocol and flow arrangement for establishing secure communications between two end-user devices;

FIG. 5 shows how the FIGS. 4A, 4B arrangement does not impact or require any changes to the communication infrastructure while nevertheless providing end-to-end security;

FIGS. 5A-5B show example message transmission protocols;

FIGS. 6A-6D show exemplary illustrative non-limiting user interface selection arrangements;

FIG. 7 shows an exemplary illustrative non-limiting end-user device architecture;

FIGS. 8A, 8B show example non-limiting data structures;

FIG. 9 shows an exemplary illustrative non-limiting flowchart of program control steps;

FIG. 10 is an illustrative non-limiting example of one way an OTP can be entered into an application such ProtectedSMS;

FIG. 11 depicts a non-limiting example of how an OTP can be applied to the exemplary ProtectedSMS Contact Registration Exchange process; and

FIG. 12 is second non-limiting example of inputting an OTP for use with the ProtectedSMS Contact Registration Exchange process.

DETAILED DESCRIPTION

One-Time Pad Used for the Exchange of Cryptographic Material

As described in parent U.S. patent application Ser. No. 12/940,213 (incorporated herein by reference), the ProtectedSMS application instantiates a secure relationship between cooperating peers with the exchange of asymmetric cryptographic public keys. This public key exchange is then used as the basis to derive key material used for symmetric encryption operations for subsequent secure message oriented communications.

The “Detailed Description” of FIGS. 1, 1A, 2, 3, 4A, 4B, 5, 5A-5B, 6A-6D, 7, 8A, 8B and 9 of above-referenced U.S. patent application Ser. No. 12/940,213 is incorporated herein by reference as if expressly set forth.

Looking at FIG. 10, during the registration message processing, the user interface component of the ProtectedSMS application may prompt for the OTP to be entered so the application can incorporate its use during the processing of the registration requests.

This process is further illustrated in FIG. 11. At step 1100, the at least two cooperating parties (Bob and Alice) determine and agree upon the OTP to use for their exchange. In one illustrative embodiment, Bob enters in the OTP via standard input methods to the ProtectedSMS application. Alice does the same at step 1120. The ProtectedSMS application may validate the OTP input to ensure it's within given policy guidelines that may be set for the application (i.e. length, upper/lower case letters, punctuation, etc.). Alternative methods of input can be easily envision by those schooled in the art. For example if a gesture is used as input on a touch screen, the application may asked the user to repeat the pattern. If a stylist is used, touching the screen at different coordinates may be used as the input for the OTP. Biometrics may also be used, where one party uses for example their thumbprint on both devices. In the scenario described above where both parties are in the same proximity, Bob and/or Alice may touch both devices as input.

Once the OTP is provided as input to the application, at step 1130 Bob's device prepares to initiate the Contact Registration Exchange. ProtectedSMS now applies the OTP to the authentication/encryption process prior to sending the registration request message. Along with his public key, ancillary information such as name, phone number, address, etc., may also be included as part of this message. Once the message is hashed and/or cipher using the OTP as part of the cryptographic process, Bob's device forwards the message over a potentially unsecure communications medium (SMS, Internet, Bluetooth, WiFi, flash memory card, etc.).

At step 1140, Alice's device receives the CRE registration request. Again, using the OTP, the ProtectedSMS application applies the OTP during its ciphering/authentication process for the message. If the message is successfully deciphered and/or authenticated, Alice is then able to accept Bob's public key and any ancillary information with the additional level of assurance that Bob originated the message.

At step 1150, after acceptance of Bob's information, Alice's device reverses the process and uses the OTP during its ciphering, authentication, and preparation of the registration response message. Alice's device then communicated the message over a potentially unsecure channel or medium (SMS, Internet, Bluetooth, WiFi, flash memory card, etc.). At step 1160, Bob's device receives the registration response message and uses the OTP in its deciphering/authentication process. If the process is successful, the ProtectedSMS application notifies Bob that the exchange has been completed and records Alice's public key along with any ancillary information for subsequent use.

In a similar manor as the ProtectedSMS application, the Protected Mobility Enterprise Console (PMEC) may also use an OTP when registering with devices that it manages/communicates with.

FIG. 12 is an example of how via a Web UI the OTP can be entered. When an operator of the PMEC system want to register a device that it will manage/securely communicate with, the PMEC application may prompt the user to enter an OTP. Alternatively, an OTP may be randomly generated for the operator using a (pseudo) random source of information such as a DRBG and convert its output into human readable form (letters, numbers, punctuation, etc.) The OTP may be communicated with the peer device through an out of band communications, such as secure enterprise email service, voice communications, etc. Alternatively, the device may actually be near the operator, where he or she may complete the registration process by entering in the OTP to the application. From that point on, the process continues in a similar fashion as to the one discussed above. Alternative methods of input and exchange of an OTP can be easily envisioned by those skilled in the art.

While the technology herein has been described in connection with exemplary illustrative non-limiting embodiments, the invention is not to be limited by the disclosure. The invention is intended to be defined by the claims and to cover all corresponding and equivalent arrangements whether or not specifically disclosed herein.

Claims

1. A method of establishing and conducting secure short message communications between plural peer devices, comprising: (a) transmitting cryptographic information to a peer device over an electronic connection;(b) securely providing, to each of the plural peer devices, a one time pad using a communication that is out of band with respect to the electronic connection including not conveying the one time pad over the electronic connection but instead using a different communications path that prevents interception of the one time pad by eavesdroppers on the electronic connection, the one time pad comprising a one time passcode or passphrase for input into each of the plural peer devices;(c) using the one time pad to authenticate the transmitted cryptographic information and/or as a seed to cipher the cryptographic information for transmission;(d) generating a shared secret from the cryptographic information; and(e) using the shared secret to securely protect short messages for exchange between the plural peer devices over the same or different electronic connection.

2. The method of claim 1 wherein the short messages comprise SMS messages.