Patent Publication Number: US-2022231859-A1

Title: Systems and methods for verifying a route taken by a communication

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
     This application is a continuation of U.S. application Ser. No. 15/652,114, filed on Jul. 17, 2017, titled “SYSTEMS AND METHODS FOR VERIFYING A ROUTE TAKEN BY A COMMUNICATION,” which is a continuation-in-part of U.S. application Ser. No. 15/588,533, filed on May 5, 2017, titled “SYSTEMS AND METHODS FOR ENABLING TRUSTED COMMUNICATIONS BETWEEN ENTITIES,” which claims priority to U.S. Provisional Application No. 62/332,271, filed on May 5, 2016, titled “DEVICE AUTHENTICATION USING A CENTRAL REPOSITORY.” The &#39;533 application also claims priority to U.S. Provisional Application No. 62/469,346, filed on Mar. 9, 2017, titled “METHODS AND SYSTEMS FOR IDENTITY MANAGEMENT.” Further, this application is related to U.S. application Ser. No. 15/652,098, titled “SYSTEMS AND METHODS FOR ENABLING TRUSTED COMMUNICATIONS BETWEEN CONTROLLERS,” U.S. application Ser. No. 15/652,108, titled “SYSTEMS AND METHODS FOR MITIGATING AND/OR PREVENTING DISTRIBUTED DENIAL-OF-SERVICE ATTACKS,” and U.S. application Ser. No. 15/652,089, titled “SYSTEMS AND METHODS FOR DISTRIBUTING PARTIAL DATA TO SUBNETWORKS,” where these three related applications were filed on Jul. 17, 2017. The disclosures of all of the above applications are hereby incorporated by reference in their entirety for all purposes. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates to computer systems and methods for verifying a route taken by a communication. More particularly, the present disclosure relates to computer systems and methods for verifying identities of the entities on a route taken by a communication. 
     BACKGROUND 
     Public-key infrastructure (PKI) enables secure transfer of information between entities without using usernames, passwords, or shared secrets. However, a PKI deployment requires certificate authorities (CAs) and validation authorities (VAs), which are single points of failure. Therefore, if a CA or VA becomes disabled or compromised, every entity that relies on the CA or the VA may become more vulnerable to attacks, such as spoofing. 
     SUMMARY 
     In one embodiment, a device for verifying a route taken by a communication may include one or more processors configured to obtain a communication transmitted by a source entity. The communication may include data and digital signatures, and each of the digital signatures may be generated based on at least the data. Further, the digital signatures may include a digital signature associated with the source entity, and a set of digital signatures associated with at least a subset of intermediate entities on a route taken by the communication. The one or more processors may be further configured to verify the digital signatures included in the communication, verify whether the entities associated with the digital signatures form an expected route for the communication, and process the data. 
     In another embodiment, a method for verifying a route taken by a communication may include obtaining a communication transmitted by a source entity. The communication may include data and digital signatures, and each of the digital signatures may be generated based on at least the data. Further, the digital signatures may include a digital signature associated with the source entity, and a set of digital signatures associated with at least a subset of intermediate entities on a route taken by the communication. The method may further include verifying the digital signatures included in the communication, verifying whether the entities associated with the digital signatures form an expected route for the communication, and processing the data. 
     In yet another embodiments, a non-transitory computer-readable storage medium storing instructions that when executed by a computer cause the computer to perform a method for verifying a route taken by a communication includes obtaining a communication transmitted by a source entity. The communication may include data and digital signatures, and each of the digital signatures may be generated based on at least the data. Further, the digital signatures may include a digital signature associated with the source entity, and a set of digital signatures associated with at least a subset of intermediate entities on a route taken by the communication. The method may further include verifying the digital signatures included in the communication, verifying whether the entities associated with the digital signatures form an expected route for the communication, and processing the data. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an example of a communication system in accordance with the disclosed embodiments. 
         FIG. 2  illustrates another example of a communication system in accordance with the disclosed embodiments. 
         FIG. 3  illustrates the communication system of  FIG. 1  after a communication destined for a destination entity is transmitted by a source entity. 
         FIG. 4  illustrates the communication system of  FIG. 3  after the communication is received and transmitted by an intermediate entity. 
         FIG. 5  illustrates the communication system of  FIG. 4  after the communication is received and transmitted by another intermediate entity. 
         FIG. 6  illustrates a process for verifying a route taken by a communication in accordance with the disclosed embodiments. 
         FIG. 7  illustrates another example of a communication system in accordance with the disclosed embodiments. 
         FIG. 8  illustrates an example data structure for the communication of the communication system in accordance with the disclosed embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments. However, embodiments may be implemented 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. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of an entirely hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense. 
     The logical operations of the various embodiments are implemented (1) as interconnected machine modules within the computing system and/or (2) as a sequence of computer implemented steps running on a computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments described herein are referred to alternatively as operations, steps or modules. 
     Aspects of the disclosure pertains to computer systems and methods for verifying a route taken by a communication. More particularly, the present disclosure relates to computer systems and methods for verifying identities of the entities on a route taken by a communication. Further, the disclosed systems and methods may be capable of verifying that the route taken by the communication includes an expected set of entities in an expected order. The disclosed systems and methods may process data in the communication after verifying the identities of the entities on a route taken by a communication and/or verifying that the route taken by the communication includes the expected set of entities in the expected order. There are several potential applications for this technology, and the scope of this disclosure is not intended to be limited to any particular business concern. 
       FIG. 1  illustrates an example of a communication system  100  in which concepts consistent with the principles of the invention may be implemented. As shown in  FIG. 1 , system  100  shows a network of entities  130  that includes a source entity  110 , a destination entity  120 , and intermediate entities  142 - 156 . 
     An entity (e.g., source entity  110 , destination entity  120 , or an intermediate entity) may be any hardware or software capable of communicating via one or more network links represented by lines connecting the entities. For example, an entity may be a host device such as an internet-of-things device, laptop, tablet, cellular phone, server, or virtual machine. In another example, an entity may be a network device such as a gateway, router, switch, or hub. In some embodiments, an entity may be a service implemented on a cloud platform, such as Amazon Web Service, Google Cloud Service, and Microsoft Azure. 
     Network links may connect entities in network of entities  130  to each other. Two entities that are connected by a network link may communicate directly with each other. A network link may be a wired link or a wireless link. For example, a network link may be an Ethernet, Wi-Fi, Bluetooth, infrared, or fiber-optic link. 
     In system  100 , source entity  110  may transmit communications that are destined for destination entity  120 . Since source entity  110  is not directly connected to destination entity  120  by a network link in system  100 , the communications may be delivered to destination entity  120  via a set of connected intermediate entities and network links connecting them (i.e., a communication route). As used herein, a communication route, or a route, refers to a set of connected entities that connect source entity  110  to destination entity  120 . For example, as shown in  FIG. 1 , the communications transmitted by source entity  110  may be delivered to destination entity  120  via a communication route  140  that includes source entity  110 , intermediate entity  142 , intermediate entity  144 , and destination entity  120 . 
     Although not illustrated in  FIG. 1 , other routes between source entity  110  and destination entity  120  exist in system  100 . For example, source entity  110  may be connected to destination entity  120  by a route that includes source entity  110 , intermediate entity  152 , intermediate entity  154 , and destination entity  120 ; a route that includes source entity  110 , intermediate entity  152 , intermediate entity  156 , intermediate entity  154 , and destination entity  120 ; and a route that includes source entity  110 , intermediate entity  142 , intermediate entity  146 , intermediate entity  148 , intermediate entity  150 , and destination entity  120 . 
     In embodiments where multiple routes exist between source entity  110  and destination entity  120 , the route taken by a communication may be selected in a number of ways. For example, a route may be selected from available routes based on the routes&#39; performance, cost, and/or availability. In some embodiments, only a single route between source entity  110  and destination entity  120  may exist. In these embodiments, the only available route may be used for the communication between source entity  110  and destination entity  120 . 
     In system  100  of  FIG. 1 , at least one intermediate entity on a communication route  140  may be capable of including additional data to the communication transmitted by source entity  110  and destined for destination entity  120 . Thus, destination entity  120  may receive a communication that includes the original data transmitted by source entity  110  and additional data added by at least one intermediate entity on the route. 
     Moreover, at least some of the communications transmitted by source entity  110  destined for destination entity  120  may be route-verifiable communications. As used herein a “route-verifiable communication” may be a communication that includes information on the route taken by the communication (i.e., route information). In some embodiments, the route information may be used by intermediate entities and/or the final recipient of the communication (e.g., destination entity  120  and/or intermediate entities) to: (i) verify identities of at least a subset of the entities on the route taken by the communication, (ii) verify the identity of the source entity, and/or (iii) verify that the route taken by the communication includes an expected set of entities in an expected order. The route information may be included, generated, and/or updated by source entity  110  and at least a subset of entities on the route taken by the communication. The use of route-verifiable communications may significantly increase the difficulty and the complexity of the attack needed to spoof a communication in system  100 . For example, instead of attacking a single entity (e.g., source entity  110 ), an attacker may need to attack every entity on route  140  to spoof a route-verifiable communication. 
     In system  100 , public/private key pairs are generated for source entity  110  and for at least one entity on route  140  using a public-key cryptography algorithm, such as an RSA. The generated private keys may be kept within the entities associated with the private keys, but the corresponding public keys may be distributed throughout system  100  so that various entities may access them.  FIG. 1  illustrates private and public keys that can be accessed by various entities in system  100 . For example, as shown in  FIG. 1 , source entity  110 , intermediate entity  142 , and intermediate entity  144  have access to their own private keys  112 ,  143 , and  145 , respectively. Further, destination entity  120  may have access to source public key  122 , intermediate entity  142 ′s public key  124 , and intermediate entity  144 ′s public key  126 . 
     While public/private key pairs have many different uses, in system  100 , a private key may be used to generate a digital signature based on given data (i.e., to “sign the data”), and a corresponding public key (i.e., a public key that was generated with the private key using the public-key cryptography algorithm) may be used to verify that the generated digital signature is indeed generated by an entity that has access to the corresponding private key. Additionally, the corresponding public key may be used to further verify that the data has not been altered since the digital signature was generated. 
     In some embodiments, digital signatures of source entity  110  and/or at least one intermediate entity (e.g., entity  142 ) on the route taken by the communication (e.g., route  140 ) may be included in the route information. That is, the digital signatures of source entity  110  and/or at least one intermediate entity may be included in the communication, and the included digital signatures may be used by destination entity  110  to verify that the communication was delivered to destination entity  120  using route  140 . 
       FIG. 2  illustrates an example of a system  200  in which additional concepts consistent with the principles of the invention may be implemented. System  200  is similar to system  100  of  FIG. 1 , except that system  200  illustrates various types of source entities, intermediate entities, and destination entities. For example, as shown in  FIG. 2 , source entities may include a cellular phone  202  and an internet-of-things device  212  deployed on an off-shore oil rig  210 . Intermediate entities may include, for example, a cellular tower  204 , an on-site gateway  214  deployed on oil rig  210 , and a remote gateway  220 . A destination entity may include, for example, a server  230  and a service implemented on a cloud platform  240 . 
       FIG. 3  illustrates communication system  100  of  FIG. 1  after a route-verifiable communication  310  destined for destination entity  120  is transmitted by source entity  110  and received at intermediate entity  142 . As shown in  FIG. 3 , communication  310  is being delivered to destination entity  120  using route  140 . Thus, communication  310  is transmitted by source entity  110  on a network link connecting source entity  110  to intermediate entity  142 , which is the first intermediate node on route  140 . 
     As shown in  FIG. 3 , communication  310  includes data  312  destined for destination entity  120  and a signature  314  associated with source entity  110 . Data  312  may be any data that may be obtained by source entity  110  and destined for destination entity  120 . For example, data  312  may include data from one or more components (e.g., sensors, user interfaces, receivers) included in, or otherwise accessible to, source entity  110 . In another example, data  312  may include a request or an instruction destined for destination entity  120 . In some embodiments, data  312  may be encrypted and/or obfuscated. 
     Signature  314  may be a digital signature generated at least based on data  312  using a private key associated with source entity  110  (i.e., source private key  112 ). A digital signature may be generated in numerous ways. In one example, a digital signature may be generated by encrypting a hash value of given data (e.g., data  312 ) using a private key (e.g., private key  112 ). In this example, a corresponding public key (e.g., public key  122 ) may be used to decrypt the digital signature and obtain the hash value of the original data. Thus, if the decrypted digital signature matches the hash value of the received data, it may prove that (i) the data was signed with a private key that corresponds to the public key, and (ii) the data has not changed since it was signed. However, if the decrypted digital signature does not match the hash value of the received data, the data has been altered and/or the digital signature was created with a private key that does not correspond to the public key. In some embodiments, a digital signature may be generated by encrypting metadata (e.g., checksum) of given data using a private key. In another example, a digital signature may also be generated by encrypting a portion or all of the given data using a private key. Here, a corresponding public key may be used to decrypt the digital signature to obtain the portion of, the data or the entire data. Subsequently, the decrypted digital signature may be compared to the received data to determine (i) that the data was signed with a private key that corresponds to the public key, and (ii) that the data has not changed since it was signed. It may be advantageous in terms of performance, however, to generate a digital signature based on a hash value rather than a portion or all of the given data because the size of a hash value is typically smaller than the size of the data. As used herein, the process of using a public key to prove that (i) the data was signed with a private key that corresponds to the public key, and (ii) the data has not changed since it was signed is referred to as “verifying the signature.” 
     In system  100 , signature  314  may have been obtained and included in communication  310  by source entity  110  before communication  310  was transmitted on the network link connecting source entity  110  with intermediate entity  142 . In some embodiments, source entity  110  may have generated signature  314 . Alternatively, source entity  110  may have caused generation of signature  314  and obtained the generated signature  314 . For example, source entity  110  may have requested another entity with access to private key  112  to generate signature  314  and obtained the generated signature  314  from the entity. In some embodiments, private key  112  may be stored and/or signature  314  may be generated using a secure element (SE), trusted platform module (TPM), or a trusted execution environment (TEE). 
     In some embodiments, communication  310  may further include header data associated with signature  314 . In these embodiments, signature  314  may be generated further based on the header data associated with signature  314 . Thus, any changes to the header data after signature  314  is generated (i.e., after the header data is signed) may be detected during verification of signature  314 . The header data associated with signature  314  may include any data available to source entity  110 . In some embodiments, the header data associated with signature  314  may include a value indicative of an order in which signature  314  is generated and/or included in communication  310 . For example, in the system of  FIG. 3 , the header data associated with signature  314  may include an index number (e.g., “0”) to indicate that signature  314  is the first signature included in communication  310 . In some embodiments, the header data associated with signature  314  may include data identifying source entity  110  and/or methods/algorithms used to generate signature  314 . 
       FIG. 4  illustrates system  100  of  FIG. 3  after entity  142  receives communication  310  and transmits a route-verifiable communication  410 . As discussed above, communication  410  is being delivered to destination entity  120  using route  140 . Thus, communication  410  is transmitted by intermediate entity  142  on a network link connecting intermediate entity  142  to intermediate entity  144 , which is the second intermediate node on route  140 . Communication  410  is similar to communication  310  of  FIG. 3  except that communication  410  further includes a signature  412  associated with intermediate entity  142 . 
     Signature  412 , similar to signature  314 , may be a digital signature generated at least based on data  312  using a private key associated with intermediate entity  142  (i.e., private key  143 ). Thus, signature  412  may be used to prove that (i) the data was signed with private key  143 , and (ii) the data has not changed since it was signed. In some embodiments, signature  412  may be generated further based on signature  314 . In these embodiments, signature  412  may be used to prove that (i) data  312  and signature  314  was signed with private key  143 , and (ii) data  312  and signature  314  have not changed since they were signed. 
     In system  100  of  FIG. 4 , signature  412  may have been obtained and included in communication  410  by intermediate entity  142  before communication  410  was transmitted on the network link connecting intermediate entity  142  with intermediate entity  144 . In some embodiments, intermediate entity  142  may have generated signature  412 . Alternatively intermediate entity  142  may have caused generation of signature  412  and obtained the generated signature  412 . For example, intermediate entity  142  may have requested another entity with access to private key  143  to generate signature  412  and obtained the generated signature  412  from the entity. In some embodiments, private key  143  may be stored and/or signature  412  may be generated using a SE, TPM, or TEE. 
     In some embodiments, prior to obtaining and/or including signature  412  in communication  410  or prior to transmitting communication  410 , intermediate entity  142  may have verified signature  314 . For example, prior to generating signature  412 , intermediate entity  142  may have verified using source public key  122  that signature  314  was indeed generated by source entity  110  and that data  312  has not been changed since it was signed by source entity  110 . In these embodiments, intermediate entity  142  may have access to public keys that are associated with immediately neighboring entities that entity  142  is expected to receive communications from. For example, in system  100 , entity  142  may have access to public keys associated with source entity  110 , entity  144 , and/or entity  146 . 
     In some embodiments, the public keys may be stored on intermediate entity  142  or a data store accessible by intermediate entity  142 . In some embodiments, the public keys may be stored on a shared data stores accessible by a plurality of entities (e.g., intermediate entity  142 , intermediate entity  144 , and/or destination entity  120 ). 
     In some embodiments, prior to obtaining and/or including signature  412  in communication  410  or prior to transmitting communication  410 , intermediate entity  142  may verify that transmitting entity (e.g., source entity  110 ) is authorized to transmit communications via intermediate entity  142 . For example, intermediate entity  142  may access a policy server and/or an authentication server to determine whether source entity  110  is authorized to transmit communications via entity  142 . In another example, intermediate entity  142  may maintain, or have access to, a list of entities that are authorized and/or capable (e.g., physically connected to intermediate entity  142 ) of transmit communications via entity  142 . In this example, intermediate entity  142  may verify that source entity  110  is included in such a list prior to obtaining and/or including signature  412  in communication  410  or prior to transmitting communication  410 . In some embodiments, intermediate entity  142  may maintain, or have access to, a list of entities that are not allowed to communicate via entity  142 . In these embodiments, intermediate entity  142  may verify that source entity  110  is not listed in such a list prior to obtaining and/or including signature  412  in communication  410  or prior to transmitting communication  410 . 
     In some embodiments, communication  410  may further include header data associated with signature  412 . In these embodiments, signature  412  may be generated further based on the header data associated with signature  412 . Thus, any changes to the header data after signature  412  is generated (i.e., after the header data is signed) may be detected during verification of signature  412 . The header data associated with signature  412  may include any data available to intermediate entity  142 . In some embodiments, the header data associated with signature  412  may include a value indicative of order in which signature  412  is generated and/or included in communication  410 . For example, in the system of  FIG. 4 , the header data associated with signature  412  may include an index number (e.g., “1”) to indicate that signature  412  is the signature included in communication  410  after signature  314 . In some embodiments, the header data associated with signature  412  may include data identifying intermediate entity  142  and/or methods/algorithms used to generate signature  412 . 
       FIG. 5  illustrates system  100  of  FIG. 4  after entity  144  receives communication  410  and transmits a route-verifiable communication  510 . As discussed above, communication  510  is being delivered to destination entity  120  using route  140 . Thus, communication  510  is transmitted by intermediate entity  144  on a network link connecting intermediate entity  144  to destination entity  120 . Communication  510  is similar to communication  410  of  FIG. 4  except that communication  510  further includes a signature  512  associated with intermediate entity  144 . 
     Signature  512 , similar to signature  412 , may be a digital signature generated at least based on data  312  using a private key associated with intermediate entity  144  (i.e., private key  145 ). Thus, signature  512  may be used to prove that (i) the data was signed with private key  145 , and (ii) the data has not changed since it was signed. In some embodiments, signature  512  may be generated further based on signature  314  and/or signature  412 . In these embodiments, signature  512  may be used to prove that (i) data  312 , signature  314 , and/or signature  412  were signed with private key  145 , and (ii) data  312 , signature  314 , and/or signature  412  have not changed since they were signed. In embodiments where communication  510  includes the header data associated with signature  314  and/or the header data associated with signature  412 , signature  412  may be generated further based on the header data associated with signature  314  and/or the header data associated with signature  412 . 
     In system  100  of  FIG. 5 , signature  412  may have been obtained and included in communication  510  by intermediate entity  144  before communication  510  was transmitted on the network link connecting intermediate entity  144  with destination entity  120 . In some embodiments, intermediate entity  144  may have generated signature  512 . Alternatively intermediate entity  144  may have caused generation of signature  512  and obtained the generated signature  512 . For example, intermediate entity  144  may have requested another entity with access to private key  135  to generate signature  512  and obtained the generated signature  512  from the entity. In some embodiments, private key  145  may be stored and/or signature  512  may be generated using a SE, TPM, or TEE. 
     In some embodiments, prior to obtaining and/or including signature  512  in communication  510  or prior to transmitting communication  510 , intermediate entity  144  may have verified one or more signatures previously included in communication  510 . For example, intermediate entity  144  may verify the signature of an entity immediately before intermediate entity  144  on route  140  (i.e., signature  412 ). In this example, intermediate entity  144  may have access to public keys that are associated with immediately neighboring entities that entity  144  is expected to receive communications from. In another example, intermediate entity  144  may verify signatures of all intermediate entities preceding intermediate entity  144  on route  140  (i.e., signature  412 ). In yet another example, intermediate entity  144  may verify all entities preceding intermediate entity  144  on route  140  (i.e., signatures  314  and  412 ). In these examples, intermediate entity  144  may have access to public keys that are associated with all entities that entity  144  is expected to receive communications from. 
     In some embodiments, the public keys may be stored on intermediate entity  144  or a data store accessible by intermediate entity  144 . In some embodiments, the public keys may be stored on a shared data stores accessible by a plurality of entities (e.g., intermediate entity  142 , intermediate entity  144 , and/or destination entity  120 ). 
     Similar to communication  410 , in some embodiments, prior to obtaining and/or including signature  512  in communication  510  or prior to transmitting communication  510 , intermediate entity  144  may verify that the transmitting entity (e.g., source entity  110 ) and/or one or more preceding intermediate entities (e.g., intermediate entity  142 ) are authorized to transmit communications via intermediate entity  144 . For example, intermediate entity  144  may access a policy server and/or an authentication server to determine whether source entity  110  and/or intermediate entity  142  are authorized to transmit communications via entity  144 . In another example, intermediate entity  144  may maintain, or have access to, a list of entities that are authorized and/or capable (e.g., physically connected to intermediate entity  144 ) of transmit communications via entity  144 . In this example, intermediate entity  144  may verify that source entity  110  and/or intermediate entity  142  are included in such a list prior to obtaining and/or including signature  512  in communication  510  or prior to transmitting communication  510 . In some embodiments, intermediate entity  144  may maintain, or have access to, a list of entities that are not allowed to communicate via entity  144 . In these embodiments, intermediate entity  144  may verify that source entity  110  and/or intermediate entity  142  are not listed in such a list prior to obtaining and/or including signature  512  in communication  510  or prior to transmitting communication  510 . 
     In some embodiments, the list(s) maintained by intermediate entity  144  may be synchronized with the list(s) maintained by other entities (e.g., intermediate entity  142 ). In some embodiments, the list(s) accessed by intermediate entity  144  may be the same as the list(s) accessed by other entities (e.g., intermediate entity  142 ). For example, the list(s) may be stored on a shared data store accessible by a plurality of entities. 
     In some embodiments, communication  510  may further include header data associated with signature  512 . In these embodiments, signature  512  may be generated further based on header data associated with signature  512 . Thus, any changes to the header data after signature  512  is generated (i.e., after the header data is signed) may be detected during verification of signature  512 . The header data associated with signature  512  may include any data available to intermediate entity  144 . In some embodiments, the header data associated with signature  512  may include data indicative of order at which signature  512  is generated and/or included in communication  510 . For example, in the system of  FIG. 5 , the header data associated with signature  512  may include an index number (e.g., “2”) to indicate that signature  512  is the signature included in communication  510  after signature  314  and signature  412 . In some embodiments, the header data associated with signature  512  may include data identifying intermediate entity  144  and/or methods/algorithms used to generate signature  512 . 
       FIG. 6  is an example of a process  600  performed or otherwise implemented by destination entity  120  after receiving route-verifiable communication  510 . Process  600  may be capable of verifying the identities of the entities on the route taken by the communication and/or verifying that the route taken by the communication includes the expected set of entities in the expected order. 
     At step  602 , destination entity  120  may obtain communication  510  transmitted by source entity  120 . The communication may include data  312  and digital signatures. Each digital signature may be generated based on at least data  312 . As discussed above, the digital signatures may include a digital signature associated with source entity  110  (e.g., signature  314 ), and a set of digital signatures associated with at least a subset of intermediate entities on route  140  taken by the communication (e.g., signatures  412  and/or  512 ). As discussed above, the digital signatures may have been obtained and/or included in communication  510  by the associated entities on route  140 . 
     At step  604 , destination entity  120  may verify the plurality of signatures included in communication  510 . For example, destination entity  120  may verify signature  314 , signature  412 , and  512  included in communication  510 . As discussed above, verifying a signature associated with an entity may include decrypting the signature using a public key associated with the entity and comparing the decrypted signature with a hash value or at least a portion of the signed data (e.g., data  312 , signature  314 , and/or signature  412 ). In some embodiments, destination entity  120  may verify the signatures of source entity  110  and the intermediate node immediately preceding destination entity  120  (i.e., intermediate entity  144 ). In an alternative step, destination entity  120  may verify the signature of the intermediate node immediately preceding destination entity  120 . 
     In some embodiments, the public keys for verifying the signatures may be stored on destination entity  120  or a data store accessible by destination entity  120 . In some embodiments, the public keys may be stored on a shared data stores accessible by a plurality of entities (e.g., intermediate entity  142 , intermediate entity  144 , and/or destination entity  120 ). In some embodiments, destination entity  120  may have access to all public keys of entities that can communicate with destination entity  120 . 
     At a step  606 , destination entity  120  may verify whether the entities associated with signatures included in communication  510  form an expected route for communication  510  transmitted by source entity  110 . For example in system  100 , destination entity  120  may expect that communications from source entity  110  to take route  140 . Thus, destination entity  120  may verify that the entities associated with the signatures include intermediate entity  142  and intermediate entity  144 . Destination entity  120  may further verify that a signature associated with source entity  110  is included in communication  510 . 
     In some embodiments, destination entity  120  may determine the expected route for a communication based on a network map of system  100 . The network map may include, for example, entities of system  100 , network links connecting the entities, and/or costs/performance/availability associated with network links. In some embodiments, destination entity  120  may have access to a look-up table that includes expected routes corresponding to a source entity. The look-up table may be stored in destination entity  120  or on another entity/data store connected to destination entity  120 , for example. 
     In some embodiments, destination entity  120  may further verify that the entities associated with signatures indicated as having been included in communication  510  in an expected order. For example, destination entity  120  may verify that signature associated with intermediate entity  142  is indicated as having been included before signature of intermediate entity  144 . Destination entity  120  may further verify that signature associated with source entity  110  is indicated as having been included before signature of intermediate entity  142 . As the indicators of the order in which the signatures are included in communication  510 , destination entity  120  may use one or more values included in the headers data that may be associated with digital signatures. As discussed above, the header data may include, for example, a value indicative of the order in which the associated signature is included in communication  510 . 
     If destination entity  120  determines that the entities associated with signatures included in communication  510  do not form the expected route for communication  510  transmitted by source entity  110 , destination entity  120  may halt process  600 . In some embodiments, communication  510  may be discarded if the entities associated with signatures included in communication  510  do not form the expected route. In some embodiments, communication  510  may be stored and/or transmitted for future examination (e.g., by an administrator) if the entities associated with signatures included in communication  510  do not form the expected route. In some embodiments, destination entity  120  transmit a communication destined for source enetiyl 10 , indicating that communication  510  was not accepted and/or processed by destination entity  120 . 
     In some embodiments, destination entity  120  may verify that the transmitting entity (e.g., source entity  110 ) and/or one or more preceding intermediate entities (e.g., intermediate entity  142  and intermediate entity  144 ) are authorized to transmit communications destined for destination entity  120 . For example, destination entity  120  may access a policy server and/or an authentication server to determine whether source entity  110 , intermediate entity  142 , and/or intermediate entity  144  are authorized to transmit communications destined for destination entity  120 . In another example, and intermediate entity  144  may maintain, or have access to, a list of entities that are authorized and/or capable (e.g., physically connected to intermediate entity  144 ) of transmit communications destined for destination entity  120 . In this example, destination entity  120  may verify that source entity  110 , intermediate entity  142 , and/or intermediate entity  144  are included in such a list. In some embodiments, destination entity  120  may maintain, or have access to, a list of entities that are not allowed to communicate with destination entity  120 . In these embodiments, destination entity  120  may verify that source entity  110 , intermediate entity  142 , and/or intermediate entity  144  are not listed in such a list. 
     In some embodiments, the list(s) maintained by destination entity  120  may be synchronized with the list(s) maintained by other entities (e.g., intermediate entity  142  and/or intermediate entity  144 ). In some embodiments, the list(s) accessed by destination entity  120  may be the same as the list(s) accessed by other entities (e.g., intermediate entity  142  and/or intermediate entity  144 ). For example, the list(s) may be stored on a shared data store accessible by a plurality of entities. 
     At step  608 , destination entity  120  may process data  312  included in communication  510 . In some embodiments, destination entity  120  may begin processing data  312  prior to step  608  and finish processing data  312  at step  608 . For example, destination entity  120  may finish processing the data after verifying the digital signatures and verifying that entities associated with the digital signatures included in communication  510  form the expected route for communication  510 . 
       FIG. 7  illustrates another example of a communication system  700  in accordance with the disclosed embodiments. System  700  is similar to system  100  as shown in  FIG. 5 , except route  140  includes an additional intermediate entity  702 . However, in contrast to other intermediate entities on route  140 , intermediate entity  702  does not include its signature in communication  510 . In some embodiments, intermediate entity  702  may be an entity incapable of modifying received communications. For example, intermediate entity  702  may be a hub or a layer- 2  switch. In some embodiments, intermediate entity  702  may be an entity configured not to add its signature. In system  700 , the routes expected by destination entity  120  may include only the intermediate entities that are known (e.g., based on a known network map of system  700  or based on a database that includes attributes of various nodes in system  700 ) to include their signatures in route-verifiable communications. Thus, in the example of  FIG. 7 , signatures of source entity  110 , intermediate entity  142 , and intermediate entity  144  are expected for route  140 . In some embodiments, destination entity  120  may maintain, or have an access to, a list of intermediate entities known to include their signatures in route-verifiable communications. 
       FIG. 8  is an example of a JavaScript Object Notation Web Token (JWT)-based data structure  800  that can be used by communication system  100  for transmitting, signing, and receiving communication  510  in accordance with the disclosed embodiments. In some embodiments, the data structure  800  may be a JSON Web Signature (JWS) or a JSON Web Encryption (JWE) data structure. 
     Data structure  800 , as shown in  FIG. 8 , includes a “payload” key-value pair and a “signatures” key-value pair. A value of the “payload” key-pair (i.e., &lt;data&gt;) may include data  312 , and a value of the “signatures” key-pair may include an array of objects. Further, each object in the array of objects may include a “protected” key-value pair and a “signature” key-value pair. A value of the “protected” key-value pair may include a value indicative of an order in which the digital signatures are included in the communication. For example, as shown in  FIG. 8 , the value of the “protected” key includes a “sidx” key-value pair, whose value is a number indicative of the order in which the digital signatures are included in the communication. A value of the “signature” key-value pair (i.e., &lt;signature X data&gt;) may include a digital signature associated with a source entity or an entity on route  140  taken by communication  510 . For example, the value of the “signature” key-value pair may include signature  314 , signature  412 , or signature  512 . 
     While illustrative embodiments have been described herein, the scope of any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations and/or alterations as would be appreciated by those skilled in the art based on the present disclosure. The limitations in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application. The examples are to be construed as non-exclusive. Furthermore, the steps of the disclosed routines may be modified in any manner, including by reordering steps and/or inserting or deleting steps. It is intended, therefore, that the specification and examples be considered as illustrative only, with a true scope and spirit being indicated by the following claims and their full scope of equivalents.