U.S. patent application number 13/552592 was filed with the patent office on 2013-08-15 for resilient device authentication system.
The applicant listed for this patent is Hal A. Aldridge, Michael J. Duren, John J. Walsh. Invention is credited to Hal A. Aldridge, Michael J. Duren, John J. Walsh.
Application Number | 20130212642 13/552592 |
Document ID | / |
Family ID | 48946771 |
Filed Date | 2013-08-15 |
United States Patent
Application |
20130212642 |
Kind Code |
A1 |
Walsh; John J. ; et
al. |
August 15, 2013 |
Resilient Device Authentication System
Abstract
A resilient device authentication system comprising: one or more
verification authorities (VAs) including a memory loaded with a
complete verification set that includes hardware part-specific
data, and configured to create a limited verification set (LVS)
therefrom; one or more provisioning entities (PEs) each connectable
to at least one of the VAs, including a memory loaded with a LVS,
and configured to select a subset of data therefrom so as to create
an application limited verification set (ALVS); and one or more
device management systems connectable to at least one of the PEs,
including a memory loaded with an ALVS, and configured to manage
device security-related applications through the performance of
security-related functions on devices associated with the hardware
part-specific data.
Inventors: |
Walsh; John J.; (Lutz,
FL) ; Duren; Michael J.; (Clearwater, FL) ;
Aldridge; Hal A.; (Tampa, FL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Walsh; John J.
Duren; Michael J.
Aldridge; Hal A. |
Lutz
Clearwater
Tampa |
FL
FL
FL |
US
US
US |
|
|
Family ID: |
48946771 |
Appl. No.: |
13/552592 |
Filed: |
July 18, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61597819 |
Feb 12, 2012 |
|
|
|
Current U.S.
Class: |
726/2 |
Current CPC
Class: |
H04L 9/3278 20130101;
H04L 9/3271 20130101; H04L 9/08 20130101; G06F 21/44 20130101 |
Class at
Publication: |
726/2 |
International
Class: |
G06F 21/00 20060101
G06F021/00 |
Claims
1. A resilient device authentication system, comprising: a. one or
more verification authorities ("VAs") including a VA memory loaded
with a complete verification set ("loaded CVS") that includes
hardware part-specific data, and configured to create a limited
verification set ("LVS") from said loaded CVS; b. one or more
provisioning entities ("PEs") each connectable to at least one of
said one or more VAs, including a PE memory loaded with a LVS
("loaded LVS"), and configured to select a subset of data from said
loaded LVS so as to create an application limited verification set
("ALVS"); and c. one or more device management systems ("DMSs")
connectable to at least one of said one or more PEs, each DMS
including a DMS memory loaded with an ALVS ("loaded ALVS"), and
configured to manage one or more device security-related
applications through the performance of security-related functions
on devices associated with hardware part-specific data in said
loaded CVS.
2. The system of claim 1, wherein all device security-related
applications managed by the system utilize said hardware
part-specific data in said loaded CVS.
3. The system of claim 1, wherein each of said one or more VAs is
configured to perform a one-way algorithmic transformation of
hardware specific data in said loaded CVS.
4. The system of claim 1, wherein each of said one or more PEs
includes a hardware security module configured to limit PE access
to LVS data.
5. The system of claim 4, wherein each of said one or more DMSs
includes a hardware security module configured to limit DMS access
to ALVS data.
6. The system of claim 1, wherein said one or more device
security-related applications include supply chain risk
management.
7. The system of claim 1, wherein said one or more device
security-related applications include device authentication.
8. The system of claim 1, wherein said one or more device
security-related applications include governing networked
communications among devices associated with hardware part-specific
data in said loaded CVS.
9. The system of claim 8, wherein said networked communications
employ a communications protocol in which addresses are based on
devices' hardware part-specific data.
10. The system of claim 9, wherein said networked communications
utilize real or virtual routers.
11. The system of claim 1, wherein said one or more VAs consists of
a single VA.
12. The system of claim 1, wherein said one or more VAs consists of
a federated group of VAs.
13. The system of claim 1, wherein said one or more VAs consists of
a siloed group of VAs.
14. The system of claim 1, wherein each of said one or more PEs is
configured to receive an LVS from a single VA.
15. The system of claim 1, wherein said one or more PEs includes a
peer network configured to share information contained in an
LVS.
16. The system of claim 15, wherein said peer network is configured
so that PEs therein are permitted to share information contained in
an LVS with a peer seeking to join the network based on a
peer-to-peer establishment of trust.
17. The system of claim 1, wherein each of said one or more DMSs is
configured to store in its DMS memory a record of device
interactions.
18. The system of claim 17, wherein said record of device
interactions is structured in a format useable by each of said one
or more device security-related applications.
19. The system of claim 18, wherein said one or more device
security-related applications include supply chain risk
management.
20. The system of claim 17, wherein each of said one or more PEs is
configured to store in its PE memory an ALVS record containing the
content of each ALVS provided by the PE to DMSs and including
identification of the recipient DMSs.
21. The system of claim 20, wherein each of said one or more VAs is
configured to store in its VA memory an LVS record containing the
content of each LVS provided by the VA to PEs and identification of
the recipient PEs.
22. The system of claim 21, wherein each of said one or more VAs is
configured to perform a one-way algorithmic transformation of
hardware specific data in said loaded CVS, and wherein each LVS
record further includes or is associated with an algorithm record
stored in said VA memory identifying the algorithm and parameters
used in the creation of LVSs it has created.
23. The system of claim 22, wherein said one or more VAs are
configured to, in response to an authorized entity's request for
tracing, provide part of its CVS record, LVS record, and algorithm
record to the authorized entity.
24. The system of claim 23, wherein said DMS is further configured
to, in response to an authorized entity's request for tracing,
provide part of its ALVS record to the authorized entity.
25. The system of claim 1, wherein said one or more VAs are
configured to create a replacement LVS.
26. The system of claim 25, wherein said one or more PEs are
configured to convey information regarding any device-level
security compromise to a VA, and said VA is configured to utilize
said information in a blacklist of CVS elements.
27. The system of claim 1, wherein said one or more PEs are
configured to construct a replacement ALVS.
28. The system of claim 27, said one or more VAs are configured to
create a replacement LVS.
29. The system of claim 27, wherein said one or more PEs are
configured to exclude, from said replacement ALVS, data that was
included in a loaded ALVS.
30. The system of claim 29, wherein said one or more PEs are
configured to construct said replacement ALVS without employing a
one-way algorithmic transformation.
31. The system of claim 3, wherein said one or more VAs are
configured to create a replacement LVS by performing a different
one-way algorithmic transformation of hardware specific data in
said loaded CVS than the one-way algorithmic transformation that
was used to create the loaded LVS.
32. The system of claim 1, wherein said loaded CVS includes
challenge-response pairs.
33. The system of claim 3, wherein said loaded CVS includes
challenge-response pairs.
34. The system of claim 33, wherein said loaded LVS includes
elements that each comprise a collection of unobfuscated challenge
value/obfuscated response value pairings, and wherein each said
element is bound to a unique identity of a hardware part having a
physically-unclonable function ("PUF").
35. The system of claim 34, wherein each of said elements is
encrypted.
36. The system of claim 34, wherein each hardware part further
includes a memory loaded with a record of algorithms and parameters
used in the creation of data contained in said loaded LVS.
37. The system of claim 36, wherein each hardware part further
includes a controller configured to process data received from the
hardware part's PUF using information contained in said record of
algorithms and parameters.
38. The system of claim 37, wherein each hardware part further
includes a memory loaded with a key that is shared with a VA but is
not shared with any DMS.
39. A method of providing resilient device authentication,
comprising: a. establishing one or more verification authorities
("VAs") each having a VA memory; b. loading one or more VA memories
with a complete verification set ("loaded CVS") that includes
hardware part-specific data; c. creating one or more limited
verification sets ("LVSs") from said loaded CVS; d. establishing
one or more provisioning entities ("PEs") each connectable to at
least one of said one or more VAs, and each having a PE memory; e.
loading each PE memory with a LVS ("loaded LVS"); f. selecting a
subset of data from said loaded LVS so as to create an application
limited verification set ("ALVS"); g. establishing one or more
device management systems ("DMSs") connectable to at least one of
said one or more PEs, each DMS including a DMS memory; h. loading
each DMS memory with an ALVS ("loaded ALVS"); and i. causing one or
more DMSs to manage one or more device security-related
applications through the performance of security-related functions
on devices associated with hardware part-specific data in said
loaded CVS.
40. The method of claim 39, wherein step c. is performed by one or
more VAs utilizing a one-way algorithmic transformation of hardware
specific data in said loaded CVS.
41. The method of claim 39, further comprising the steps of
connecting a PE to a VA, and conveying an LVS from the VA to the
PE.
42. The method of claim 41, further comprising the step of a VA
storing a LVS record containing the content of each LVS provided by
it to PEs and an identification of the recipient PEs.
43. The method of claim 39, further comprising the steps of
connecting a DMS to a PE, and conveying an ALVS from the PE to the
DMS.
44. The method of claim 43, further comprising the step of a PE
storing an ALVS record containing the content of each ALVS provided
by it to DMSs and an identification of the recipient DMSs.
45. The method of claim 39, wherein step i. further includes said
one or more DMSs storing a record of device interactions.
Description
RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. provisional
patent application Ser. No. 61/597,819 filed Feb. 12, 2012 and
entitled "Key Management Utilizing Physically-Unclonable Functions,
and Cyber-Physical Security Measures," which is incorporated herein
by reference.
BACKGROUND
[0002] Managing authentication and identity across systems, users,
and enterprises is complex and threat-prone, and increasingly so as
endpoints and cloud-based systems continue proliferating. Current
solutions for identity management, authentication, and key
management are typically disparate in nature and confined in design
and purpose to specific applications (e.g., network authentication
protocols, PKIs, code-signing, biometrics, etc.). Various methods
for deploying identity authentication technologies in contexts such
as "smart grids," cloud computing, and enterprise networks and
network extensions typically include a variety of applications that
would require a number of dissimilar prior art technology
solutions, so as to complicate and multiply overall design,
planning, and cryptographic-related overhead.
[0003] The manufacturing and provisioning costs and burdens
associated with establishing "hardware biometrics" (i.e.,
observable intrinsic features of hardware device material, design,
or manufacturing process that can uniquely differentiate a specific
device from other devices of the same or similar type) to enable
secure device identification, registration, and management are not
insignificant. Hitherto, the presumably attendant limitations and
ongoing added operating complexity, risk, and overhead would have
discouraged attempts to employ hardware biometrics in any types of
architectures known to Applicant for managing and authenticating
identities across systems, users, and enterprises, as would be
required for a manufacturing through end-use approach.
SUMMARY OF THE INVENTION
[0004] Applicant has devised a novel system architecture employing
hardware biometrics that can avoid the aforementioned ongoing
disadvantages, and can outweigh the upfront costs and burdens by
virtue of system operating efficiency and reduced costs of trust
management and compromise. The present Resilient Device
Authentication ("RDA") system enables a holistic development and
management of systemic trust mechanisms grounded in physical
hardware and extending into the manufacturing process, operating
systems, applications, and whole systems, and can be deployed
efficiently in a system having a range of diverse applications,
throughout the system's lifecycle. Thus hardware-anchored
security-related functions that could be performed by applications
in various embodiments of an RDA system may include, among many
other things, authentication, supply chain security functions,
encryption, policy management, data or document certification, key
management, etc.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 depicts an embodiment of an RDA system according to
the present invention, showing its hierarchical control, flow, and
use of device verification information among and by three levels of
entities.
[0006] FIG. 2 depicts an embodiment of a system like that shown in
FIG. 1, except that each entity in the lowest level (Distributed
Management Systems) universally handles functions that are split
between the corresponding entities in the embodiment of FIG. 1,
also showing the system's basic divisions according to function or
loci.
[0007] FIG. 3 depicts part of the system of an embodiment like
those of FIGS. 1 and 2, showing further details of the Verification
Authority.
[0008] FIG. 4A is a representation of a set of 1-N parts (P) having
corresponding verification information (V) of different types.
[0009] FIG. 4B is a representation of a set of data elements
comprising verification information collected for Part N.
[0010] FIG. 5 is a diagram like that of FIG. 3, but with a siloing
of Verification Authorities and data by class.
[0011] FIG. 6 depicts the top-down data provisioning model of an
embodiment of an RDA system.
[0012] FIG. 7 depicts a specific example of a provisioning in the
embodiment of FIG. 6.
[0013] FIG. 8 depicts the change or updating of a Limited
Verification Set in an embodiment of an RDA system.
[0014] FIG. 9 depicts the change or updating of an Application
Limited Verification Set in an embodiment of an RDA system.
[0015] FIG. 10 depicts a segmentation of Complete Verification Set
data in an embodiment of an RDA system.
[0016] FIG. 11 depicts a segmentation of data and algorithms in an
embodiment of an RDA system.
[0017] FIG. 12 is a partial circuit diagram of a device that can be
used in an embodiment of an RDA system that manages devices with
hardware parts having PUFs.
[0018] FIG. 13 is a partial circuit diagram of another version of a
device like that of FIG. 12.
DETAILED DESCRIPTION OF EMBODIMENTS
[0019] The following acronyms are used for basic aspects of the
present system: [0020] "CVS" refers to the Complete Verification
Set, which is a super-set of hardware-based part-authentication
data. [0021] "LVS" refers to a Limited Verification Set, which is a
set of data that is derived from part of the CVS. [0022] "ALVS"
refers to an Application Limited Verification Set, which is a
subset of elements chosen from part of an LVS. [0023] "VA" refers
to a Verification Authority, which stores the CVS and creates and
distributes LVSs therefrom. [0024] "PE" refers to a Provisioning
Entity, which stores an LVS and constructs and distributes ALVSs
therefrom. [0025] "DMS" refers to a Device Management System, which
stores an ALVS and uses it to authenticate devices (i.e., specific
hardware parts) in the system.
[0026] Referring to FIGS. 1 and 2, an embodiment of an RDA system
100 according to the present invention can manage
authentication-related functions for diverse applications such as
supply chain risk management ("SCRM") 131, authentication 132, and
other applications 133 (e.g., device management, access management,
connectivity management, etc.), using the foundation of a CVS 110
for all hardware verification and authentication functions. The CVS
is provided to a VA 120, which distributes an LVS 111 based on the
CVS to a PE 121 (or, not shown, the system preferably includes
multiple PEs to each of which the VA distributes a different LVS),
which in turn provides ALVSs 112.sub.1-N, to DMSs 122.sub.1-N,
which then directly interface with the applications.
[0027] The CVS is an essentially static database comprising
part-specific data elements 160 for all hardware parts 140 (see
FIG. 4B) in the system. Preferably each of the elements of the CVS
is bound to the unique identity of one specific part, and
preferably each part has a plurality of elements bound to it. The
database preferably includes significantly disparate types of
elements and multiple elements of usefully-unrelated information
for each part, so as to permit strong, feature-rich authentication.
Such data elements can include (but are not limited to) various
parameters, information, validation material, processes, and
secrets, etc. such as challenge/response pairs, physical elements
that can be remotely interrogated, shared secret information
embedded during manufacture, and physical properties that can be
used to model a device. CVS elements may be used directly for
authentication, may be used as characteristic values for deriving
authentication methods tied to a device, and may be sub-divided and
allocated such as for a particular use or verification process.
Specific elements may contribute different features to the
authentication process, for example one being used to identify the
physical device while another is a revocable component (e.g.,
relational information such as a device's registered location).
Confidentiality, integrity, assurance, and performance can be
managed through the selection of revocable and non-revocable
elements to be included in the CVS.
[0028] The CVS includes device-level--and preferably
chip-level--security data elements based on one or more types of
hardware features such as physically-unclonable functions ("PUFs")
150, PUF-derived data, physical features of a design, etc. Such
data elements can be formed, derived, revealed, and recorded,
and/or tested for presence, robustness, and applicability at the
time of manufacture. For example, in the case of a PUF, the loading
and characterization of device may occur upon fabrication of an
application specific integrated circuit ("ASIC") or initial
programming of a field-programmable gate array ("FPGA").
[0029] Referring to FIG. 3, once the CVS database is created and
collected, it is supplied to a VA 120, which stores it in memory
135. The VA is responsible for: (1) securely storing and managing
the CVS; (2) managing requests for LVSs 111; (3) processing CVS
data to create LVSs; and (4) distributing LVSs. The VA owner must
be able to protect and handle the CVS data at an assurance level at
least commensurate with the requirements of the system's most
sensitive parts and applications, and typically would be a
manufacturer, high-level program entity, or service provider. If a
system is intended to manage parts having different security
classes (e.g., commercial, government, and classified as shown in
FIG. 4A), CVS data preferably may be grouped by reliability,
detection, and variability properties, and allocated through the
system according to the applicable information assurance
requirements and uses of different applications. In such cases, CVS
data also can be siloed between multiple VAs having corresponding
different levels of security and LVS algorithms 130 as shown by the
unmarked, single-asterisked, and double-asterisked siloes in FIG.
5, or a single-VA system could have an architecture that is
similarly internally-siloed. Thus, as depicted by the asterisks in
FIG. 11, a different security level of algorithm can be used to
create LVS 111.sub.2 than the one used to create LVS 111.sub.1
(whereas in the non-siloed system shown in FIG. 10 the same
security level of algorithms is used to create both LVSs, albeit
using different CVS elements). Depending on security requirements,
higher-security VAs or internal siloes optionally also (not shown)
could receive and process lower-security CVS data; for example, a
classified-level VA could handle not just the classified parts of
the CVS but also commercial and government parts.
[0030] Whether siloed or not, a federation of multiple VAs each
limited to a separate subset of CVS data optionally could be
employed, possibly communicating CVS-related data among each other
with measures to prevent any VA owner from deriving another's CVS
data subset. In a federated VA embodiment, for example one VA could
store parts' CRPs while another VA stores parts' secret keys. This
federated structure could support, for example, a federated
identity brokering system such as that disclosed in U.S. Pat. No.
7,581,248 to Atkins et al., the disclosure of which is incorporated
herein by reference. Such a combination, with the present RDA
system providing the data used to implement authentication, would
provide a federated identity structure useable with cloud and other
distributed applications that has the added benefit of
hardware-based authentication.
[0031] Referring to FIG. 2, the VA does not frequently distribute
an LVS during the operation phase, but only as a result of need for
initial provisioning by a PE 121, request 114 to recover a
compromised or lost LVS, or policy-dictated update. The VA derives
an LVS's elements from CVS elements that comprise, or more
preferably are chosen from, a subset of elements applicable to the
recipient PE. The VA should be configured to ensure that each LVS
it creates includes representation of CVS elements adequate to: a)
redundantly verify all of the parts managed by the recipient PE;
and b) satisfy all of the applicable applications, accounting for
the degree of usefulness that each type of element has in each
application (e.g., SCRM, device management, access management,
connectivity management, etc.). The VA retains a record of all LVS
data it has distributed (and the CVS elements, algorithms, and
parameters used in their creation) and to which PEs, enabling
tracing of part-specific CVS elements down to a PE.
[0032] Referring to FIGS. 6 & 7, each LVS 111.sub.1-N is
derived from the CVS in a way that produces new (though related)
data, utilizing subset CVS data as input parameters in algorithms
that include cryptography (e.g., hashing such as with SHA-1 or
SHA-2 families), randomness, and/or physical models. One-way
algorithms are preferably chosen that preclude reverse construction
of CVS elements from any or all distributed LVSs even if the
algorithms and parameters that were used to create them are known.
Depending on the level of assurance desired for a system,
algorithmic complexity (and quality and orthogonality of CVS data)
also should be sufficient to make available virtually infinite LVS
algorithms (and thus derivable LVSs) or at least preclude the
future repeat of any LVS elements and/or parts thereof given the
applicable exposure factors such as the system's anticipated
service life, the frequency of updates and recoveries, etc. (If
less assurance is required and where none of the data at issue is
compromised, the VA could be configured to redistribute an LVS lost
by a PE).
[0033] The LVS is distributed to a PE--typically owned by an
application owner or program operator--which securely stores its
LVS in a memory 136, and when needed (e.g., upon initial DMS
provisioning, DMS-requested recovery, regular update, VA-initiated
reprovisioning, etc.), chooses a subset of elements from its LVS
adequate to uniquely identify each part managed by a specific DMS
122 in its domain, and preferably without one-way algorithmic
transformation, provides the chosen elements to that DMS in the
form of an ALVS 112, which the DMS stores in memory 137. The system
preferably is configured to preclude (or at least intelligently
limit) reuse of LVS elements by a PE, so each PE maintains a record
of all ALVSs it has provided (and to which DMSs, enabling tracing
down to them).
[0034] DMSs may be provided with mutually-exclusive
(non-overlapping) ALVS data elements, or the RDA system may be
configured so that ALVS data is shared or synchronized (for example
the system may be configured so that one DMS would need to
re-confirm an attribute that another DMS has already confirmed for
its application) among multiple DMSs in a domain, in which case
coordination thereof may be managed by the responsible PE. A system
may be configured so that all DMSs communicate directly with their
PE to obtain all new or updated ALVSs, or configured so that
certain ALVS data is obtained via peer-to-peer sharing among DMSs.
In the latter case, DMSs could establish trust among each other
(and optionally, re-keying could be effected) using the methods
taught in Applicant's co-pending application Ser. No. 13/163,086
(the disclosure of which is incorporated herein by reference), with
the DMSs being the nodes and the PE being the central authority.
(Such peer-to-peer sharing could also greatly enhance the
scalability of a given PE's domain). Each DMS communicates directly
with fielded devices, using its ALVS data to perform
application-specific security-related functions for various
applications such as SCRM, authentication, encryption, etc. A DMS
may be confined to an exclusive or an overlapping "enclave" that is
limited geographically (e.g., a cellular communications tower and
the devices authorized to communicate with it), by application, by
program, etc. Each DMS records a log of all of its device
interactions, for operational accounting and traceability
purposes.
[0035] Global, straightforward traceability to trusted
hardware-specific security information is enabled through the VA's
static CVS data/part bindings in conjunction with the DMSs' and the
PEs' records tracking down to specific transactions with individual
devices. (Such records also may be required to enable various
applications' security-related functions). Since operational data
(ALVS/LVS) can be protected with one-way algorithmic obfuscation
(and/or encryption), however, such data cannot be tied directly to
any useable CVS element without information that only the VA
possesses and controls for secure use as needed.
[0036] An RDA system may be configured so that DMSs can use the
results of authentication checks to authorize, promote, inhibit, or
block interactions between specified machines, software modules,
hardware modules, systems, and/or users. As one example, a DMS
could check the parts in a supply chain each day (e.g., to confirm
that they are the same as the day before), and could temporarily
shut down or permanently disable part or all of a system if certain
types of compromises (e.g., suspected counterfeiting) are
detected.
[0037] An RDA system also may be configured in which devices
communicate with each other using real or virtual routers using a
communications protocol (e.g., packetized) that utilizes
identification based on each device's hardware part-specific data
instead of an IP address or the like. For example, devices could be
networked through real routers that communicate with, are
operationally configured by, and receive real-time authorized
device identifications (and preferably also corresponding permitted
communications for each device) from DMSs. Or one or more devices
could be programmed (individually, or using distributed computing
and/or data) to perform such routing functions virtually. In either
case, a graphic user interface may be incorporated into DMSs
(and/or at another level) to provide for network management
including router configuration, policy administration, etc. The DMS
preferably would be configured to disable network communication by
any devices that may be affected by compromise, automatically in
response to specified device interactions or other indications of
compromise.
Top-Level Firewall, Tailored Middle- and Lower-Level Recovery
Processes
[0038] As discussed above, different types of data sets--CVS, LVS,
and ALVS--are used at each vertical level of the system. Whereas
the VA is on-demand only, the DMSs (and PEs to the extent a system
has synchronized ALVS) control normal operational use of
verification data for multiple applications controlled/owned by the
system and thus may face greater exposure; it also may be
impractical to implement all of the same security measures used by
the VA at the levels below. Cementing the distinction between CVS
versus LVS/ALVS with the one-way algorithms that are used to derive
LVSs from CVS data, however, effectively firewalls the latter from
potentially lower assurance levels underneath the VA. (The same
distinction also enables security against top-down risk vectors--if
the CVS itself were somehow compromised, still the VA would be able
to create and distribute new LVSs that are secure in that new
algorithms and parameters not known to the VA at the time of
compromise would be employed).
[0039] The distinction between CVS, LVS, and ALVS likewise enables
the tailoring of correspondingly distinct ALVS and LVS recovery
processes so as to permit the enforcement of vigilant security
policies at the level of use without incurring much (or in some
cases, any) system-wide overhead. Since DMSs are at the level of
use, they and the elements in their data sets are exposed to the
most likely and frequent source of direct compromise in the system
(namely, the variety of fielded devices with which the DMSs
constantly interact). Correspondingly, the ALVS recovery process
preferably is straightforward and has little or no collateral
impact on PEs (and their respective DMSs) other than the PE in
whose domain the recovering DMS exists, and depending on the
embodiment preferably may also have little or no collateral impact
on the other DMSs in the same domain. Thus, a DMS that needs a new
or updated ALVS 112.sub.new (due to loss or compromise of the
existing ALVS 112.sub.old, and/or DMS-enforced policy) makes a
recover request 115 to the PE (or in the case of peer-to-peer DMSs,
possibly to one or more peer DMSs) including information regarding
any compromise, and the PA just selects a group of
previously-unused elements from its LVS and provides it to the DMS
(as shown in FIG. 9 versus FIG. 7) and possibly conveys
compromise-related information up to the VA. (The VA preferably
processes such information and includes it as appropriate in a
blacklist 137 of any compromised underlying CVS elements and/or
hardware, and depending on the VA's policies and the specific
compromise(s) at issue, pushes a new LVS (or LVSs) down, in
response to which the affected PE(s) distribute new ALVSs). Only at
the middle level (i.e., PE), where recovery should be needed less
frequently, is a somewhat more burdensome recovery process used. If
a PE no longer has enough useable elements to construct new ALVSs,
it makes a recover request to the VA, which creates and provides
the PE a new LVS 111.sub.new to replace the old LVS 111.sub.old
(see FIG. 8), and the PE selects and pushes new ALVSs therefrom to
the DMSs in its domain.
Additional Security Measures
[0040] Security compromises should not require device-level
replacement, because ALVS compromises only affect specific subsets
of LVS elements and in any case the CVS is effectively firewalled
against LVS data compromises; further, the newly-created
information employed in LVS algorithms would ameliorate even the
case of direct compromise of a CVS itself. Nevertheless, it may be
preferable to layer additional security measures, such as keyed and
encrypted communications between all or specified entities, onto
the RDA system's inherent security. In the case of communications
between DMSs and devices, such additional measures could be
enhanced further by sharing with a part a secret value or key that
identifies the specific hardware security feature or sub-feature
(e.g., the location of PUF sub-circuits) to be used in
authenticating that part.
Embodiment Utilizing CRP Data
[0041] Referring to FIGS. 12 and 13, an embodiment of an RDA system
can manage devices 170 with hardware parts 140 having PUFs 150.
PUFs may be characterized through the cataloguing of numerous
challenge response pairs ("CRPs") upon manufacture or initial
programming of an FPGA. (The validation of such PUFs through the
use of CRPs is described in U.S. Pat. No. 7,839,278 to Devedas et
al. and U.S. Patent Application Publication Nos. 2011/0066670 to
Yu, 2011/0033041 to Yu et al., 2010/0272255 to Devedas et al., and
2010/0127822 to Devedas et al., the disclosures in that regard of
which are incorporated herein by reference). This cataloguing
produces a table of CRPs for each part, which can then be divided
into a plurality of smaller tables each of which is stored (along
with a binding to the unique identity of the corresponding part) as
an element in the CVS database. The VA can be configured to produce
an LVS element from such a CRP-based CVS element by obfuscating the
response value of each of the element's pairs one-by-one using a
suitable one-way algorithm as discussed above (e.g., hashed with
parameters and a key), and re-pairing the resulting obfuscated
response value with each corresponding non-obfuscated challenge
value. The resulting challenge/obfuscated-response pairs for the
element then also could be encrypted using suitable known
encryption means, either pair-by-pair (and then reassembled along
with the element's binding information) or all together (but
preferably before joining the binding information). Alternately the
initial complete table of CRPs for a part could be stored (along
with a binding to the unique identity of the corresponding part)
undivided as a single element in the CVS database, and the VA
create an LVS element from it by choosing a number of (preferably
not all) CRPs from the element's CRP table, one-way obfuscating the
response value of each of the chosen pairs one-by-one, re-pairing
each resulting obfuscated response value with the corresponding
non-obfuscated challenge value, and if desired encrypting
pair-by-pair or element-by-element and then joining the binding
information. Prior to the foregoing encryption, challenge values
additionally might be individually encrypted with an encryption key
that is derived (such as with a hashing algorithm) from a base key
known only to the VA and the system's devices (preferably by
securely embedding or otherwise providing it in them at the time of
their fabrication); such a system then also could be partitioned
using different base keys that are specific, e.g., to a particular
PE's domain's (or even DMS's enclave's) devices.
[0042] The VA joins the LVS elements it creates for the parts in a
particular PE's domain to produce an LVS, and provides it
(preferably encrypted) to that PE. The recipient PE then can search
the LVS's part-identity binding information (which is preferably
stored in the elements unencrypted and/or external to the elements
themselves, so as to avoid unnecessarily unencrypting all LVS
elements), identify the subset of elements that is relevant to a
particular DMS, choose some of those elements with which to
construct an ALVS, and provide that to the DMS (preferably via a
communication that is encrypted). The recipient DMS then
(unencrypting the elements if necessary) can utilize the ALVS's
relevant elements to manage various applications' security-related
functions that comprise or involve interaction with one or more
devices 170 (e.g., via an input/output 175 the device is provided
with). While the ALVS elements contain useable PUF challenge data,
however, the valid response data for the corresponding responses is
obfuscated in a manner (i.e., one-way) such that it is unknowable
to the DMS. Consequently, the DMS can only verify a device in the
field responding to its challenge if the response matches the
obfuscated one known to the DMS. This can be accomplished by
including in each device 170 (or alternately as shown in FIG. 13,
in every part 140) a memory 180 in which is loaded the specific
algorithm and parameter information (e.g., specific hash function,
and other inputs) that was used by the VA to create the elements
pertaining to that device (or part, in the embodiment of FIG. 13)
in the responsible PE's current LVS, and a controller 190 capable
of performing the same algorithmic transformation (using the
information in the memory) on responses generated by the PUF
150.
[0043] The algorithm and parameter information stored in each
memory 180 preferably may be conveyed there from the VA in a
special element, which, upon the issuance or updating of an LVS,
the recipient PE distributes to each DMS in its domain, which in
turn convey the special elements on to each device they manage. In
such case, each LVS is associated with as many special elements as
there are devices in the recipient PE's domain, and the special
elements preferably are sent alongside the corresponding LVS but
not stored in the PE's or DMSs's memories. To minimize the risk
associated with the compromise of any given device, the VA
preferably employs a different algorithm and/or parameters for each
CRP pair, or at least for each CRP-based LVS element, and the
corresponding collection of algorithm and parameter information for
each LVS element bound to parts in a given device (or in the
embodiment of FIG. 13, bound to a given part) is contained in each
special element. Each special element preferably may be encrypted
with a specific key derived from (e.g., with a hash) a specific
individual key known only to the VA and the particular respective
device (or part) in which it is embedded or otherwise provided at
the time of manufacture. The system in that case also could be
configured to allow re-keying of specific keys via communication
from the VA to pertinent devices through the PE/DMS without
exposing specific key-related information to the PE's and DMS's
that can be used by them--for example by the VA transmitting a
challenge value (preferably one not included in any LVS) and
causing each device (or part) receiving it to transform (e.g.,
hash) its ensuing response using its individual key, and
thenceforth employ the resulting value as its new specific key.
Embodiment Utilizing Hardware Security Modules
[0044] Rather than using a one-way algorithmic transformation to
protect CVS data from exposure at the PE and DMS levels, an
embodiment of an RDA system otherwise as described above could be
configured to provide CVS subset data to PEs (and PEs subsets
thereof to DMSs) without one-way transformation, but governed by
hardware security modules ("HSMs") incorporated into each PE and
DMS (and possibly VAs, depending on the architecture). In a
PUF-based embodiment utilizing device characterization models for
example, the HSMs (e.g., Thales e-Security Inc.'s model nC3023E-500
(nShield F2 PCI Express)) could permit only a selected portion or
portions of a given device's characterization model to be useable
by PEs and DMSs in which the model is stored. HSMs also could be
used as an additional measure to protect one-way transformed LVS
and ALVS data.
[0045] One skilled in the art will appreciate that other
variations, modifications, and applications are also within the
scope of the present invention. Thus, the foregoing detailed
description is not intended to limit the invention in any way,
which is limited only by the following claims and their legal
equivalents.
* * * * *