U.S. patent application number 17/460837 was filed with the patent office on 2022-07-21 for systems and methods for verifying a route taken by a communication.
This patent application is currently assigned to Neustar, Inc.. The applicant listed for this patent is Neustar, Inc.. Invention is credited to Brian R. KNOPF, Mark WATSON.
Application Number | 20220231859 17/460837 |
Document ID | / |
Family ID | 1000006244887 |
Filed Date | 2022-07-21 |
United States Patent
Application |
20220231859 |
Kind Code |
A1 |
KNOPF; Brian R. ; et
al. |
July 21, 2022 |
SYSTEMS AND METHODS FOR VERIFYING A ROUTE TAKEN BY A
COMMUNICATION
Abstract
Computer systems and methods for verifying a route taken by a
communication are disclosed. In one implementation, 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.
Inventors: |
KNOPF; Brian R.; (Woodland
Hills, CA) ; WATSON; Mark; (San Francisco,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Neustar, Inc. |
Reston |
VA |
US |
|
|
Assignee: |
Neustar, Inc.
Reston
VA
|
Family ID: |
1000006244887 |
Appl. No.: |
17/460837 |
Filed: |
August 30, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15652114 |
Jul 17, 2017 |
11108562 |
|
|
17460837 |
|
|
|
|
15588533 |
May 5, 2017 |
10404472 |
|
|
15652114 |
|
|
|
|
62332271 |
May 5, 2016 |
|
|
|
62469346 |
Mar 9, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 9/14 20130101; H04L
63/126 20130101; H04L 63/123 20130101; H04L 63/062 20130101; H04L
9/088 20130101; H04L 9/3247 20130101; H04L 9/321 20130101 |
International
Class: |
H04L 9/32 20060101
H04L009/32; H04L 9/40 20060101 H04L009/40; H04L 9/14 20060101
H04L009/14; H04L 9/08 20060101 H04L009/08 |
Claims
1. A device for verifying a route taken by a communication, the
device comprising: one or more processors configured to: obtain a
communication transmitted by a source entity, wherein: the
communication includes data and digital signatures, each of the
digital signatures is generated based on at least the data, and the
digital signatures 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 the route taken by the
communication; verify the digital signatures included in the
communication; verify whether entities associated with the digital
signatures included in the communication form an expected route for
the communication; and process the data.
2. The device of claim 1, wherein the data is processed after
verifying the digital signatures and verifying that the entities
associated with the digital signatures included in the
communication form the expected route for the communication.
3. The device of claim 1, wherein the processing of the data
includes: begin processing the data; and finish processing the data
after verifying the digital signatures included in the
communications and verifying that the entities associated with the
digital signatures included in the communication form the expected
route for the communication.
4. The device of claim 1, wherein the communication further
includes header data, and wherein one of the digital signatures
included in the communication is generated further based on the
header data.
5. The device of claim 4, wherein the header data includes a value
indicative of an order in which the one of the digital signatures
is included in the communication.
6. The device of claim 1, wherein the set of digital signatures are
generated further based on the digital signature associated with
the source entity.
7. The device of claim 1, wherein a digital signature of the set of
digital signatures is included in the communication by an
intermediate entity on the route after verifying at least one of
the digital signatures included in the communication.
8. The device of claim 1, the data is processed after verifying
that one or more entities associated with the digital signatures
included in the communication are authorized to communicate with
the device.
9. The device of claim 1, wherein the data is encrypted.
10. The device of claim 1, wherein the communication is in a JSON
Web Token (JWT) format including a "payload" key-value pair and a
"signatures" key-value pair, wherein: a value of the "payload"
key-pair includes the data, a value of the "signatures" key-pair
includes an array of objects, and each object in the array of
objects including: a "protected" key-value pair, and a "signature"
key-value pair, wherein: a value of the "protected" key-value pair
includes a value indicative of an order in which the digital
signatures are included in the communication, and a value of the
"signature" key-value pair including a digital signature included
in the communication.
11. A method for verifying a route taken by a communication, the
method comprising: obtaining a communication transmitted by a
source entity, wherein: the communication includes data and digital
signatures, each of the digital signatures is generated based on at
least the data, and the digital signatures 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; 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.
12. The method of claim 11, wherein the data is processed after
verifying the digital signatures and verifying that the entities
associated with the digital signatures included in the
communication form the expected route for the communication.
13. The method of claim 11, wherein the processing of the data
includes: begin processing the data; and finish processing the data
after verifying the digital signatures included in the
communications and verifying that the entities associated with the
digital signatures included in the communication form the expected
route for the communication.
14. The method of claim 11, wherein the communication further
includes header data, and wherein one of the digital signatures
included in the communication is generated further based on the
header data.
15. The method of claim 14, wherein the header data includes a
value indicative of an order in which the one of the digital
signatures is included in the communication.
16. The method of claim 11, wherein the set of digital signatures
are generated further based on the digital signature associated
with the source entity.
17. The method of claim 11, wherein a digital signature of the set
of digital signatures is included in the communication by an
intermediate entity on the route after verifying at least one of
the digital signatures included in the communication.
18. The method of claim 11, wherein the data is encrypted.
19. The method of claim 11, wherein the communication is in a JSON
Web Token (JWT) format including a "payload" key-value pair and a
"signatures" key-value pair, wherein: a value of the "payload"
key-pair includes the data, a value of the "signatures" key-pair
includes an array of objects, and each object in the array of
objects including: a "protected" key-value pair, and a "signature"
key-value pair, wherein: a value of the "protected" key-value pair
includes a value indicative of an order in which the digital
signatures are included in the communication, and a value of the
"signature" key-value pair including a digital signature included
in the communication.
20. 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,
the method comprising: obtaining a communication transmitted by a
source entity, wherein: the communication includes data and digital
signatures, each of the digital signatures is generated based on at
least the data, and the digital signatures 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; 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.
Description
CROSS-REFERENCE TO RELATED APPLICATION(S)
[0001] 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 '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
[0002] 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
[0003] 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
[0004] 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.
[0005] 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.
[0006] 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
[0007] FIG. 1 illustrates an example of a communication system in
accordance with the disclosed embodiments.
[0008] FIG. 2 illustrates another example of a communication system
in accordance with the disclosed embodiments.
[0009] FIG. 3 illustrates the communication system of FIG. 1 after
a communication destined for a destination entity is transmitted by
a source entity.
[0010] FIG. 4 illustrates the communication system of FIG. 3 after
the communication is received and transmitted by an intermediate
entity.
[0011] FIG. 5 illustrates the communication system of FIG. 4 after
the communication is received and transmitted by another
intermediate entity.
[0012] FIG. 6 illustrates a process for verifying a route taken by
a communication in accordance with the disclosed embodiments.
[0013] FIG. 7 illustrates another example of a communication system
in accordance with the disclosed embodiments.
[0014] FIG. 8 illustrates an example data structure for the
communication of the communication system in accordance with the
disclosed embodiments.
DETAILED DESCRIPTION
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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'
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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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."
[0033] 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).
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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).
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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).
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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 enetiyl10, indicating that communication 510
was not accepted and/or processed by destination entity 120.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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., <data>) 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., <signature X data>) 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.
[0064] 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.
* * * * *