阅读说明：本技术 用于使用消息级安全性进行消息传递的设备、方法和制造产品 (Apparatus, method and article of manufacture for message delivery using message level security ) 是由 Y·吴 R·韦斯特 于 2019-01-15 设计创作，主要内容包括：方法包括：建立客户端与提供WEB服务的服务器之间的传输层安全性连接；在所述连接中识别用于与WEB服务的通信的至少一个密码密钥；关闭连接；并且使用WEB服务令牌在客户端与WEB服务之间进行通信,所述WEB服务令牌按照所识别的至少一个密码密钥来签署和加密。在客户端与WEB服务之间使用WEB服务令牌进行通信可以不要求新传输层安全性连接的创建。另外的实施例提供一种配置成执行如上所述的操作的计算机以及存储指令的计算机可读介质,所述指令在由计算机执行时执行如上所述的操作。(The method comprises the following steps: establishing a transport layer security connection between a client and a server providing WEB services; identifying, in the connection, at least one cryptographic key for communication with a WEB service; closing the connection; and communicating between the client and the WEB service using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key. The use of WEB service tokens for communication between a client and a WEB service may not require the creation of a new transport layer security connection. Further embodiments provide a computer configured to perform the operations described above and a computer readable medium storing instructions that, when executed by the computer, perform the operations described above.)

1. A method of operating a client, the method comprising:

establishing a transport layer security connection with a server providing WEB services;

identifying, in the connection, at least one cryptographic key for communication with the WEB service;

closing the connection; and

communicating with the WEB service using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key.

2. The method of claim 1 wherein communication with the WEB service using the WEB service token does not require creation of a new transport layer security connection.

3. The method of claim 1 wherein identifying at least one cryptographic key comprises identifying a client private key and a server public key, and wherein communicating with the server using the signed WEB service token comprises transmitting the WEB service token signed according to the client private key and encrypted according to the server public key.

4. The method of claim 1 wherein identifying at least one cryptographic key comprises identifying a client public key and a server private key, and wherein communicating with the server using the signed WEB service token comprises receiving the WEB service token signed according to the server private key and encrypted according to the client public key.

5. The method of claim 1, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

wherein identifying at least one cryptographic key for the WEB service in the connection comprises:

transmitting the voucher;

receiving a first WEB service token of the WEB service corresponding to the certificate; and

exchanging security credentials with the WEB service using the first WEB service token to identify the at least one cryptographic key; and

wherein communicating with the WEB service using the WEB service token comprises communicating with a second WEB service token, the second WEB service token being signed and encrypted according to the identified at least one cryptographic key.

6. The method of claim 1 wherein the WEB service token comprises a signed and encrypted JavaScript object notation (JSON) WEB service token (JWT).

7. The method of claim 6, wherein the JWT uses a JSON WEB Sign (JWS) format and a JSON WEB Encryption (JWE) format.

8. A computer configured to perform the method of claim 1.

9. A computer-readable medium storing instructions that, when executed by a computer, perform the method of claim 1.

10. A method of operating a server, the method comprising:

establishing a transport layer security connection with a client;

identifying, in the connection, at least one cryptographic key for communication with a WEB service hosted by the server;

closing the connection; and

communicating with the client using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key.

11. The method of claim 10 wherein communication with the client using the WEB service token does not require creation of a new transport layer security connection.

12. The method of claim 10 wherein identifying at least one cryptographic key comprises identifying a server public key and a client private key, and wherein communicating with the server using the signed WEB service token comprises receiving the WEB service token signed according to the client private key and encrypted according to the server public key.

13. The method of claim 10 wherein identifying at least one cryptographic key comprises identifying a server private key and a client public key, and wherein communicating with the server using the signed WEB service token comprises transmitting the WEB service token signed according to the server private key and encrypted according to the client public key.

14. The method of claim 10, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

wherein identifying at least one cryptographic key for the WEB service in the connection comprises:

receiving a credential;

transmitting a first WEB service token of the WEB service corresponding to the credential; and

exchanging security credentials with the client using the first WEB service token to identify the at least one cryptographic key; and

wherein communicating with the client using the WEB service token comprises communicating with a second WEB service token, the second WEB service token being signed and encrypted according to the identified at least one cryptographic key.

15. The method of claim 10 wherein the WEB service token comprises a signed and encrypted JavaScript object notation (JSON) WEB service token (JWT).

16. The method of claim 15, wherein the JWT uses a JSON WEB Sign (JWS) format and a JSON WEB Encryption (JWE) format.

17. A computer configured to perform the method of claim 10.

18. A computer-readable medium storing instructions that, when executed by a computer, perform the method of claim 10.

19. A method of communicating between a client and a WEB service, the method comprising:

establishing a transport layer security connection between the client and a server providing the WEB service;

identifying, in the connection, at least one cryptographic key for communication with the WEB service;

closing the connection; and

communicating between the client and the WEB service using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key.

20. The method of claim 19 wherein communicating between the client and the WEB service using WEB service tokens does not require creation of a new transport layer security connection.

Background

The present subject matter relates to computer networking methods, apparatus, and articles of manufacture, and more particularly to methods, apparatus, and articles of manufacture for secure communications in computer networks.

Networking applications typically involve the communication of messages between a sending node and a receiving node via various other intermediate nodes. Due to 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 parties at an intermediate node and alters the communication between the parties by masquerading as one of the parties.

Conventional techniques for protecting against MITM attacks typically employ some type of authentication to establish a secure channel between the parties and use the secure channel to establish one or more cryptographic keys to be used to protect 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 symmetric keys for communication between parties during the session. The handshake typically involves the exchange of one or more security certificates, the verification of the exchanged certificate(s) by the certificate authority, and the establishment of a symmetric key in response to the verification of the certificate(s). For the rest of the TLS (or SSL) session, the symmetric key is used to encrypt messages between the parties.

Disclosure of Invention

Some embodiments of the present subject matter provide methods of operating a client. The method comprises the following steps: establishing a transport layer security connection with a server providing WEB services; identifying at least one cryptographic key for communication of a WEB service in the connection; closing the connection; and communicating with the WEB service using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key. In some embodiments, communication with a WEB service using a WEB service token does not require the creation of a new transport layer security connection.

According to some embodiments, identifying the 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 the WEB service token signed according to the client private key and encrypted according to the server public key. According to further embodiments, identifying the at least one cryptographic key may include identifying a client public key and a server private key, and wherein communicating with the server using the signed WEB service token includes receiving the WEB service token signed according to the server private key and encrypted according to the client public key.

In some embodiments, identifying at least one cryptographic key for the WEB service in the connection may include: transmitting the voucher; receiving a first WEB service token of a WEB service corresponding to the certificate; security credentials are exchanged with the WEB service using the first WEB service token to identify the at least one cryptographic key. Communicating with the WEB service using the WEB service token may include communicating with a second WEB service token, the second WEB service token being signed and encrypted according to the identified at least one cryptographic key.

In some embodiments, the WEB service token may comprise a signed and encrypted JavaScript object notation (JSON) WEB service token (JWT). JWT can use the JSON WEB Sign (JWS) format and the JSON WEB Encryption (JWE) format.

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

Some embodiments of the inventive subject matter provide methods of operating a WEB service. The method comprises the following steps: establishing a transport layer security connection with a client; identifying, in the connection, at least one cryptographic key for communication with a WEB service hosted by a server; closing the connection; and communicating with the client using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key. Communication with the client using the WEB service token may not require the creation of a new transport layer security connection.

In some embodiments, identifying the 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 the WEB service token signed according to the client private key and encrypted according to the server public key. In further embodiments, identifying the 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 the WEB service token signed by the server private key and encrypted by the client public key.

According to some embodiments, identifying at least one cryptographic key for the WEB service in the connection may include: receiving a credential; transmitting a first WEB service token of the WEB service corresponding to the credential; and exchanging security credentials with the client using the first WEB service token to identify the at least one cryptographic key. Communicating with the client using the WEB service token may include communicating with a second WEB service token, the second WEB service token being signed and encrypted according to the identified at least one cryptographic key.

Still other embodiments of the present subject matter provide methods of communicating between a client and a WEB service. The method comprises the following steps: establishing a transport layer security connection between a client and a server providing WEB services; identifying, in the connection, at least one cryptographic key for communication with a WEB service; closing the connection; and communicating between the client and the WEB service using a WEB service token, the WEB service token being signed and encrypted according to the identified at least one cryptographic key. The use of WEB service tokens for communication between a client and a WEB service may not require the creation of a new transport layer security connection.

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

Drawings

FIG. 1 is a schematic diagram illustrating a network environment in which the present subject matter may be applied.

Fig. 2 is a flow diagram illustrating operations for secure communications according to some embodiments of the present subject matter.

Fig. 3 is a flow diagram illustrating operations for secure communications according to further embodiments.

FIG. 4 is a schematic diagram illustrating a client-server system in which embodiments of the present subject matter may be employed.

Fig. 5 is a message flow diagram illustrating a registration operation in the system of fig. 4.

FIG. 6 is a message flow diagram illustrating a firmware update operation for the system of FIG. 4.

FIG. 7 is a message flow diagram illustrating a de-registration (de-registration) operation in the system of FIG. 4.

Detailed Description

Specific exemplary embodiments of the present subject matter will now be described with reference to the accompanying drawings. The 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 numbering represents 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 present subject matter. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless expressly specified otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, terms, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, terms, 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 the subject matter of this invention 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 this 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 result from the following recognition: reduced overhead and potentially increased resistance to MITM and other attacks may be provided by message passing between a client and a WEB service using a message-level security scheme that uses a WEB service token (e.g., JavaScript object notation (JSON) WEB token (JWT)) signed and encrypted under a private/public key pair established in an initial TLS (or SSL) connection that establishes a bilateral root of trust. The WEB service token can be used for communication after the initial transport layer secure connection is closed, thus eliminating the need to establish a new TLS connection for each communication session between the client and the server. The key used to generate the WEB service token can be terminated by expiration with respect to the payload included therein and/or can be terminated by the client or the WEB service.

This approach can be particularly advantageous in applications where communication sessions between clients and WEB services occur sporadically. As described herein, 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, for example. This approach can reduce the overhead for such communications, can reduce the likelihood that credentials used to access the WEB service can be intercepted, and can also allow both the client and the WEB service to initiate communications due to the bilateral nature of the trust relationship.

FIG. 1 illustrates a network environment in which embodiments of the present subject matter may be employed. A client 112 residing at a client device 110 (e.g., a computer, mobile terminal, or other device) is configured to communicate with a WEB service 122 residing at a server 120 (e.g., a computer, base station, or other device) via a network 130. The client 112 and WEB service 122 are configured to provide message level secure communication functions 114 and 124, which message level secure communication functions 114 and 124 provide message level security that eliminates the need for duplicate creation of TLS/SSL sessions.

In particular, referring to FIG. 2, a connection to Transport Layer Security (TLS) is established between a client 112 and a WEB service 122 via a network 130 (block 210). While the connection exists, at least one key pair for subsequent communications between the client 112 and the WEB service 122 is identified (block 220). After closing the connection (block 230), the client 112 and the WEB service 122 can continue to communicate with each other (block 240) using the WEB service token, which is signed and encrypted by the at least one key pair. This allows communication to occur without re-establishing a new transport layer secure connection.

Fig. 3 illustrates operations according to further embodiments. The TLS connection is established between the client and the WEB service using any of a number of known techniques (block 310). To initiate the establishment of the bilateral root of trust, the client passes credentials (e.g., username/password) to the WEB service (block 320). In response, the WEB service authenticates the credential and returns an authentication token to the client (block 330). Using the authentication token, the client and server exchange security credentials and identify the public/private key (block 340). The TLS connection is then terminated (block 350). The client and server then communicate using the WEB service token, signing and encrypting the WEB service token using the identified public/private key pair (block 360). The WEB service token key pair may then be invalidated by the WEB service unilaterally and/or in response to, for example, expiration of a predetermined validity period or a request from the client.

As described above, communication operations along the lines described above may be advantageously used in applications where clients and Web services communicate on a sporadic basis. For example, referring to fig. 1, a smart grid or other utility monitoring system may employ a plurality of smart devices, such as meters 440 and sensors 450, linked via radio links to a tower gateway base station (TGB) 430. The TGB 430 may be linked to a firmware manager client 412 residing at the remote device 410 via a network 420. Firmware manager client 412 may be configured to update firmware on TGB 430 via communication with one or more WEB services 432 residing at TGB 430, the one or more WEB services 432 collecting data from meters 440 and sensors 450.

Fig. 5 illustrates a representative message flow for registration between such manager client and TGB WEB services, in accordance with further embodiments. After initiation of the TLS session (501), the manager transmits a login request, which includes a username and password credentials (502). After verifying the credentials, the WEB service generates a JavaScript object notation (JSON) WEB service token (JWT) for use during the authentication process (503), and passes the token to the manager (504). The manager and WEB service use authentication JWT to exchange security credentials and responsively identify private/public key pairs for the manager and server (505-. The manager then assigns a unique ID for TGB Web service save and validate (513-. Next, the manager sends a URL that the TGB Web service can use to download the firmware package (package), which the TGB Web service saves and validates (516-. The manager then transmits a request for a token to be invalidated 519, and the WEB service responsively invalidates the token and indicates the invalidation to the manager 520 and 521. The TLS connection may then be terminated 522.

Following this registration process, communications between the client and the WEB service may then proceed using the private/public key pair identified during the TLS session. In particular, a client may initiate such communications by transmitting a JWT signed by its private key (e.g., using the JSON WEB Signing (JWS) compact serialization format as defined in IETF RFC 7515) and encrypted by the server's public key (e.g., using the JSON WEB Encryption (JWE) compact serialization format as defined in IETF RFC 7516). 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 signed by its private key and encrypted by the client's public key.

For example, fig. 6 illustrates operations for monitoring a configuration of software residing at a tower in the system of fig. 4. The manager transmits a message instructing the TGB to refresh its copy of the list of software packages from the software repository ("repository" in fig. 6) that holds the expected (up-to-date) list (610). The transport creates the JWT using the previously established key pair, thus eliminating the need for login. The location of the repository may previously be communicated from the manager to the TGB in a message that includes the location of the repository (e.g., URL) and the credentials required to access the repository. The TGB transmits a request for a manifest to the repository using the previously established location and credentials (620) and receives a manifest file from the repository (630). The TGB saves the manifest file, which is compared at the TGB with the current installation package (640 and 650). The TGB reports the results to the manager (660).

Fig. 7 illustrates operations for deregistration (unregister) according to further embodiments. Along the lines described above, a TLS session is created between the manager and the TGB (701). The manager transmits a login request including a username/password combination (702), and the TGB generates and transmits a JWT that is used to generate a key pair for use in subsequent messaging (703 and 704). Subsequently (e.g., after one or more message exchanges), the manager may transmit a "deregistration" request message (705). In response, the TGB deletes the public key associated with the JWT for the request (706) and acknowledges the deregistration request (707). The manager may then transmit a logoff request (708), and the TGB responsively invalidates the token (invalidates the key). Subsequent token-enabled communication between the manager and the tower will require re-establishment of the bilateral root of trust, as described above with reference to fig. 5.

It will be appreciated that the implementations described above with reference to fig. 4-7 are provided for illustrative purposes only, and that the inventive subject matter may be implemented in accordance with any of a number of different applications.

In the drawings and specification, there have been disclosed exemplary embodiments of the inventive subject matter. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the inventive subject matter being defined by the following claims.