Patent Description:
Networking applications generally involve the communication of messages between a sending node and a receiving node via various other intermediate nodes. Because of the need to communicate via these intermediate nodes, such communications can be vulnerable to interception, spoofing and other forms of attack. For example, such communications can be vulnerable to so-called "man in the middle" (MITM) attacks in which an attacker intercepts messages from the parties at an intermediate node and alters communications between parties by masquerading as one of the parties.

Conventional techniques for securing against MITM attacks typically employ some type of authentication to establish a secure channel between parties and using the secure channel to establish one or more cryptographic keys to be used to secure subsequent communications between the parties. For example, transport layer security (TLS) (and its predecessor, secure sockets layer (SSL)), typically involves initiating a session using a handshake protocol that establishes a symmetric key for communication between the parties during the session. The handshake typically involves an exchange of one or more security certificates, verification of the exchanged certificate(s) by a certificate authority, and establishment of a symmetric key in response to the verification of the certificate(s). For the remainder of the TLS (or SSL) session, the symmetric key is used to encrypt messages between the parties. <CIT> discloses a method and system for secure online transactions with message-level validation. <CIT> discloses a system, apparatus, method, and program product for authenticating a communication partner using an electronic certificate containing personal information <CIT> discloses a method of transferring the control of a security module from a first entity to a second entity.

Some embodiments of the inventive subject matter provide methods of operating a client according to claim <NUM>.

According to some embodiments, identifying at least one cryptographic key may include identifying a client private key and a server public key and communicating with the server using the signed web service token may include transmitting a web service token signed according to the client private key and encrypted according to the server public key. According to further embodiments, identifying at least one cryptographic key may include identifying a client public key and server private key and wherein communicating with the server using the signed web service token comprises receiving a web service token signed according to a server private key and encrypted according to a client public key.

Identifying at least one cryptographic key for a web service in the connection includes transmitting a credential, receiving a first web service token for the web service corresponding to the credential, exchanging security certificates with the web service using the first web service token to identify the at least one cryptographic key. Communicating with the web service using a web service token includes communicating with a second web service token that is signed and encrypted according to the identified at least one cryptographic key.

In some embodiments, the web service token may include a signed and encrypted JavaScript Object Notation (JSON) web service token (JWT). The JWT may use a JSON web signing (JWS) format and a JSON web encryption (JWE) format.

Further embodiments provide a computer configured to perform client operations as described above. Additional embodiments include computer-readable medium storing instructions that, when executed by a computer, perform client operations as described above.

Some embodiments of the inventive subject matter provide methods of operating a server according to claim <NUM>.

In some embodiments, identifying at least one cryptographic key may include identifying a server public key and a client private key and communicating with the server using the web service token may include receiving a web service token signed according to a client private key and encrypted according to the server public key. In further embodiments, identifying at least one cryptographic key may include identifying a server private key and a client public key and communicating with the server using the signed web service token may include transmitting a web service token signed according to the server private key and encrypted according to the client public key.

Identifying at least one cryptographic key for a web service in the connection includes receiving a credential, transmitting a first web service token for the web service corresponding to the credential, and exchanging security certificates with the client using the first web service token to identify the at least one cryptographic key. Communicating with the client using a web service token includes communicating with a second web service token that is signed and encrypted according to the identified at least one cryptographic key.

Still further embodiments of the inventive subject matter provide methods of communicating between a client and a web service according to claim <NUM>,.

Further embodiments provide a computer configured to perform web service operations as described above. Additional embodiments provide computer-readable medium storing instructions that, when executed by a computer, perform web service operations as described above.

Specific exemplary embodiments of the inventive subject matter now will be described with reference to the accompanying drawings. This inventive subject matter may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive subject matter to those skilled in the art. In the drawings, like numbers refer to like items. It will be understood that when an item is referred to as being "connected" or "coupled" to another item, it can be directly connected or coupled to the other item or intervening items may be present. As used herein the term "and/or" includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the inventive subject matter. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms "includes," "comprises," "including" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, items, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, items, components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this inventive subject matter belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Some embodiments of the inventive subject matter arise from a realization that reduced overhead and potentially increased resistance to MITM and other attacks may be provided by messaging between a client and a web service using a message-level security scheme that uses web service tokens (e.g., JavaScript Object Notation (JSON) web tokens (JWTs)) that are signed and encrypted according to private/public key pairs that are established in an initial TLS (or SSL) connection that establishes a bilateral root of trust. The web service tokens can be used for communications after the initial transport layer secured connection is closed, thus eliminating the need for establishing a new TLS connection for each communication session between the client and the server. The keys for the generating the web service tokens can be terminated by expiration in relation to a payload included therein and/or can be terminated by the client or web service.

This approach can be particularly advantageous in applications in which communications sessions between the client and the web service occur sporadically. As explained herein, for example, such techniques may be advantageously used in communications between a firmware manager client and a web service provided by a tower gateway base station (TGB) that serves a plurality of meters or other sensing devices. This approach can reduce overhead for such communications, can reduce the likelihood that credentials for accessing the web service may be intercepted, and also can allow both the client and the web service to initiate communications due to the bilateral nature of the trust relationship.

<FIG> illustrates a network environment in which embodiments of the inventive subject matter may be employed. A client <NUM> resident at a client device <NUM> (e.g., a computer, mobile terminal or other device) is configured to communicate with a web service <NUM> resident at a server <NUM> (e.g., a computer, base station, or other device) via a network <NUM>. The client <NUM> and the web service <NUM> are configured to provide a message-level secured communications functions <NUM> and <NUM> that provide message-level security that obviates the need for repeated creation of TLS/SSL sessions.

In particular, referring to <FIG>, a connection with transport layer security (TLS) is established between the client <NUM> and the web service <NUM> via the network <NUM> (block <NUM>). While the connection is present, at least one key pair for subsequent communication between the client <NUM> and the web service <NUM> are identified (block <NUM>). After the connection is closed (block <NUM>), the client <NUM> and the web service <NUM> can continue to communicate with one another using web service tokens that are signed and encrypted according to the at least one key pair (block <NUM>). This allows the communications to occur without the need to re-establish a new transport layer secured connection.

<FIG> illustrates operations according to further embodiments. A TLS connection is established between a client and a web service using any of a number of known techniques (block <NUM>). To initiate establishment of a bilateral root of trust, the client transfers a credential (e.g., a username/password) to the web service (block <NUM>). In response, the web service authenticates the credential and returns an authentication token to the client (block <NUM>). Using the authentication token, the client and server exchange security certificates and identify public/private keys (block <NUM>). The TLS connection is then terminated (block <NUM>). Subsequently, the client and server communicate using web service tokens that are signed and encrypted using the identified public/private key pairs (block <NUM>). The web service token key pairs may be subsequently be invalidated unilaterally by the web service and/or responsive to, for example, expiration of a predetermined validity period or a request from the client.

As noted above, communications operations along the lines described above may be advantageously used in applications in which client and web service communicate on a sporadic basis. For example, referring to <FIG>, a smart grid or other utility monitoring system may employ multiple smart devices, such as meters <NUM> and sensors <NUM>, which are linked to a tower gateway base station (TGB) <NUM> via radio links. The TGB <NUM> may be linked via a network <NUM> to a firmware manager client <NUM> resident at a remote device <NUM>. The firmware manager client <NUM> may be configured to update firmware on TGB <NUM> via communication with one or more web services <NUM> resident at the TGB <NUM> that gather data from the meters <NUM> and sensors <NUM>.

<FIG> illustrates a representative message flow for registration between such a manager client and TGB web service according to further embodiments. After initiation of a TLS session (<NUM>), the manager transmits a login request, including username and password credentials (<NUM>). After verifying the credentials, the web service generates a JavaScript Object Notation (JSON) web service token (JWT) for use during an authentication process (<NUM>), and transmits the token to the manager (<NUM>). The manager and the web service exchange security certificates using the authentication JWT and responsively identify private/public key pairs for the manager and the server (<NUM>-<NUM>). The manager then assigns the TGB web service a unique ID, which the TGB web service saves and acknowledges (<NUM>-<NUM>). This is followed by the manager sending URLs that the TGB web service can use to download firmware packages, which the TGB web service saves and acknowledges (<NUM>-<NUM>). The manager subsequently transmits a request for the token to be invalidated (<NUM>), and the web service responsively invalidates the token and indicates the invalidation to the manager (<NUM> and <NUM>). The TLS connection may then be terminated (<NUM>).

After this registration process, communications between the client and the web service may then be conducted using the private/public key pairs identified during the TLS session. In particular, the client may initiate such communications by transmitting a JWT that is signed according to its private key, e.g., using a JSON Web Signing (JWS) compact serialization format as defined in IETF RFC <NUM>, and encrypted according to the server's public key, e.g., using a JSON Web Encryption (JWE) compact serialization format as defined in IETF RFC <NUM>. The server can decrypt such a token using its private key and verify that the signature of the token corresponds to the client. Similarly, the server can initiate communications by transmitting a JWT that is signed according to its private key and encrypted according to the client's public key.

For example, <FIG> illustrates operations for monitoring the configuration of software resident at a tower in the system of <FIG>. The manager transmits a message that instructs the TGB to refresh its copy of a manifest of software packages from a software repository ("Repository" in <FIG>) that possesses the desired (up to date) manifest (<NUM>). The transmission creates a JWT using the previously established key pairs, thus obviating the need for login. The location of the repository may be previously transmitted from the manager to the TGB in a message that includes the location (e.g., URL) of the repository and credentials needed to access the repository. The TGB transmits a request for the manifest to the repository using the previously established location and credentials (<NUM>), and receives a manifest file from the repository (<NUM>). The TGB saves the manifest file compares it to the currently installed packages at the TGB (<NUM> and <NUM>). The TGB reports the result to the manager (<NUM>).

<FIG> illustrates operations for unregistering according to further embodiments. Along lines described above, a TLS session is created between the manager and the TGB (<NUM>). The manager transmits a login request including a username/password combination (<NUM>), and the TGB generates and transmits a JWT that is used to generate key pairs for use in subsequent messaging (<NUM> and <NUM>). Subsequently (e.g., after one or more message exchanges), the manager may transmit an "unregister" request message (<NUM>). In response, the TGB deletes the public keys associated with the JWT for the request (<NUM>), and acknowledges the unregistration request (<NUM>). The manager may then transmit a logout request (<NUM>), and the TGB responsive invalidates the token (invalidates the keys). Subsequent token-enabled communications between the manager and the tower will require re-establishment of a bilateral root of trust as explained above with reference to <FIG>.

It will be appreciated that the implementation described above with reference to <FIG> is provided for purposes of illustration only, and that the inventive subject matter may be implemented in any of a number of different applications.

Claim 1:
A method of operating a client (<NUM>), the method comprising:
establishing a transport layer security connection with a server (<NUM>) that provides a web service (<NUM>);
identifying at least one cryptographic key for communication with the web service (<NUM>) in the transport security layer connection comprising:
transmitting a credential comprising a username and a password from the client (<NUM>) to the server (<NUM>) over the transport layer security connection;
receiving a first web service token for the web service (<NUM>) corresponding to the credential from the web service over the transport layer security connection; and
exchanging security certificates with the web service (<NUM>) over the transport layer security connection using the first web service token to identify the at least one cryptographic key;
closing the transport layer security connection; and
communicating data with the web service (<NUM>) using a second web service token that is signed and encrypted according to the identified at least one cryptographic key to communicate the data without retransmitting the credential to the server (<NUM>) to create a new transport layer security connection.