Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
TRUSTED HARDWARE NETWORK INTERCONNECTION DEVICE AND
RESOURCES, AND INTEGRATED MULTI-LEVEL OR CROSS-DOMAIN
NETWORK SECURITY MANAGEMENT APPLIANCE, PLATFORM AND SYSTEM
FIELD OF THE DISCLOSURE
[001] The present disclosure relates to trusted network infrastructures,
and, in
particular, to a trusted hardware network interconnection device and
resources, and
integrated multi-level or cross-domain network security appliance and system.
BACKGROUND
[002] The provision, customization and management of secure network
infrastructure
is an ongoing challenge in the provision of secure, accurate and reliable
network services
and resources, for example, as there is an ongoing and increasing desire for
such services
and resources.
[003] As one example, hardware security modules (HSM) are known to provide
a
physical computing device that safeguards and manages digital keys for digital
system
authentication and cryptographic processing. For example, HSMs routinely form
part of
mission-critical infrastructures such as public key infrastructures or online
banking
applications. These modules traditionally come in the form of a plug-in card,
or an external
device that attaches directly to a computer or network server.
[004] In external device implementations, a hardware processor and storage
device is
provided within a tamper-resistant casing or the like so to minimize
unauthorized access
and hardware tampering, while also occasionally providing tamper evidence
logging. An
external input/output interface is provided via PCMCIA (Personal Computer
Memory Card
International Association), PC Card interface, Smart Card interface, USB port,
or any other
communication interface that may be design specific and that links to an
internal memory
used for storing private keys and like data in an associated key space, and a
cryptographic
engine for processing these keys for an intended purpose (authentication
and/or
authorization, encryption/decryption, etc.). A PCI or PCIe (Peripheral
Component
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
Interconnect Express) interface can alternatively be provided to result in a
similar
implementation. Using this approach, various HSMs may be interconnected within
a
network architecture to provide various data security services, generally, in
a one-to-one
fashion (i.e. one HSM per network security function).
[005] In network implementations, a network attached HSM may take the form
of a
standard HSM communicatively linked to an appliance server (e.g. application
layer
interface) or the like that intermediates access to the HSM and can thus allow
a same
network attached HSM to interface with distinct services. For instance, HSM
access
software executed on the appliance server can sort through various inbound
requests
.. received from distinct network-accessible sources and channels and manage
processing of
such requests by the HSM over a singular server-HSM channel. Ultimately, the
HSM is
executed in response to the appliance server and thus generally remains blind
to the sorting
and management functions of the appliance server.
[006] The SafeNet Luna SA / Network HSM (Gemalto, Belcamp, MD, e.g. see
https://safenet. gem alto. com/data-encrypti on/hardware-se curity-m odul e s-
hsm s/safenet-
network-hsm/) provides one example of a network HSM in which multiple HSM
hardware
storage partitions can be defined to secure corresponding cryptographic keys.
These keys
are stored to service corresponding network applications via an onboard access
software
that provides the network linking services on the appliance, that executes
programmed
logic to interface with the partitioned key spaces on one side, and the
various network
applications on the other via corresponding secured network connections (i.e.
SSL).
Accordingly, a common HSM network interface can be used to concurrently
service
various network applications or clients over respective secure network
connections thereto,
while also providing partitioned storage solutions to store application-
specific keys in
distinct storage partitions.
[007] A few of the HSMs available in the market today have the ability to
execute
specially developed modules within the HSM's secure enclosure. Such ability is
useful, for
example, in cases where special algorithms or business logic has to be
executed in a secured
and controlled environment. For example, HSMs provided by Thales e-Security
2
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
(Plantation, FL, e.g. see http s ://www. thal es-e security . com/products-and-
services/
products-and-services/hardware-security-modules) promote the ability to host
critical
applications within the HSM' s security boundary so to establish tamper-
resistant business
processes (i.e. executed within a generally anti-tamper running environment)
in addition to
protecting cryptographic operations.
[008] U. S . Patent Application publication No. 2013/0219164 describes
Cloud-Based
Hardware Security Modules in which a cloud-based HSM provides core security
functions
of a physically controlled HSM, such as a USB HSM, while allowing user access
within
the cloud and from a user device, including user devices without input ports
capable of
direct connection to the HSM. The HSMs can be connected to multi-HSM
appliances on
the organization or user side of the cloud network, or on the cloud provider
side of the
cloud network. HSMs can facilitate multiple users, and multi-HSM appliances
can
facilitate multiple organizations.
[009] International Application publication No. WO 2016/099644 describes
Systems
and Methods for Using Extended Hardware Security Modules that possess
additional
security properties relative to conventional HSMs and methods for
initializing, deploying,
and managing such extended HSMs in a networked environment. An extended HSM is
described to generally include additional hardware and software components
that configure
it to run sensitive client tasks on demand inside a cloud-hosted, anti-tamper
HSM housing
so as to ensure sensitive data is encrypted when stored or processed outside
the housing.
By deploying virtualization technology inside the extended HSM, virtual HSMs
may be
implemented as virtual machines or more efficient light-weight operating
system-level
virtualized containers. As such, a single extended HSM host may run one or
more
virtualized extended HSM guests in respective virtualized spaces. Namely, a
host HSM
may provide a virtual network interface functionality to a guest using its
underlying
hardware network interface to implement the provided network interface
functionality.
[0010]
Furthermore, multi-level network architectures are commonly deployed, for
instance, where disparate networking resources are required to establish
particular network
data paths across and particularly between network zones and/or interfaces in
order to
3
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
deliver a particular service or application. Physical separation between
network resources
is also commonplace in high security implementations, for example, where
physically
isolated network security zones may be required to secure back end resources
for instance
deployed in a high security zone from public and/or low security authorized
user zones. In
some high security installations, the establishment of physically isolated
networking
devices/appliances is in fact a requirement to satisfy security compliance
standards beyond
basic commercial networking standards, such as described in the Federal
Information
Processing Standard (FIPS 140-2) document published by the United States
National
Institutes of Standards and Technology (NIST), for example, and above.
Accordingly, a
network security zoning architecture may be invoked to physically separate a
high security
zone in which a sensitive restricted-access database or application server is
implemented,
from a public access zone operated in accordance with reduced access security
standards
so to allow greater user access and operation.
[0011]
Generally, a multi-level network architecture, such as a network security
zoning
architecture, will take the form of a stack of distinct network-enabled
devices,
interconnected in accordance with a designated operational network design via
a series of
corresponding physical network interface controllers and cables, to relay
data, commands
and instructions over a set of established (secured) data channels. In doing
so, reasonable
security strength can be achieved by virtue of the respective physical
segregation of the
externally interconnected networking devices, though network tampering may
nonetheless
result from physical reconnection of the subject devices, unauthorized local
access via
external physical connection to one or more of the subject devices,
introduction of an
unauthorized hacking device, or again by unauthorized reallocation of software-
defined
ports and/or data channels on tampered or otherwise compromised devices, to
name a few
examples. It is therefore considered critical to also ensure the physical
security of such
architectures.
[0012]
Alternative solutions to physically segregated network devices may include the
virtualization of certain network resources through software so as to combine
multiple such
resources on a same networking device or appliance. Accordingly, rather than
to physically
interconnect networking devices as above, a set of virtual network interface
controllers
4
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
may be configured in software to define appropriate virtual interfaces between
the various
network components virtualized on a same physical device. In the context of
network
security zoning, system designers may seek to at least partially collapse a
given network
zoning architecture into one or more virtualization zones (e.g. physically
segregated zone-
by-zone virtualization or physically aggregated zone virtualizations ¨ see for
example,
Network Segmentation in Virtualized Environments by vmware:
http s ://www.vmware.
com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/netwo
rk segmentation.pdf). Contrary to its physical implementation, a virtualized
zoning
architecture will interconnect virtualized servers via virtual switches,
network interface
controllers and the like to reduce required hardware. In doing so, the system
becomes easier
to implement and customize through software management applications, but also
becomes
more vulnerable to misconfigurations of, or tampering with, the virtualized
system
components, which may result in loss of zone isolations and/or data breaches
[0013]
This background information is provided to reveal information believed by the
applicant to be of possible relevance. No admission is necessarily intended,
nor should be
construed, that any of the preceding information constitutes prior art or
forms part of the
general common knowledge in the relevant art.
SUMMARY
[0014]
The following presents a simplified summary of the general inventive
concept(s) described herein to provide a basic understanding of some aspects
of the
disclosure. This summary is not an extensive overview of the disclosure. It is
not intended
to restrict key or critical elements of embodiments of the disclosure or to
delineate their
scope beyond that which is explicitly or implicitly described by the following
description
and claims.
[0015] A need exists for a trusted hardware network interconnection device
and
resources that overcomes some of the drawbacks of known techniques, or at
least, provides
a useful alternative thereto. Some aspects of this disclosure provide examples
of such
devices and related processes.
5
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0016] In
accordance with one aspect, there is provided a trusted hardware network
interconnection device and resources.
[0017] In
accordance with another aspect, there is provided a hardware security
module, hardwired port interconnection matrix, and embedded communication
channel
resources operable on selected hardware port-specific data communicated via
this matrix.
[0018] In
accordance with one aspect, there is provided a hardware security module
comprising: two or more hardware ports, each one of which operable to
electronically
receive given input hardware port-specific cryptographic data thereon to
initiate execution
of an internal cryptographic process as a function thereof; two or more
segregated hardware
port-specific storage spaces, each operatively linked to a corresponding
hardware port via
a corresponding hardware link, and storing respective secured hardware port-
specific
cryptographic data thereon exclusively retrievable upon said given input
hardware port-
specific cryptographic data corresponding thereto and being received via said
corresponding hardware port; a cryptographic engine operable to execute said
cryptographic process based on said secured port-specific cryptographic data
retrieved
from said segregated hardware port-specific storage spaces as a function of
said given input
port-specific cryptographic data; and a hardwired port interconnection matrix
that
operatively interconnects at least some of said hardware ports in accordance
with
predefined hardwired port-specific logic and invokes an embedded communication
channel
resource operable on selected hardware port-specific data communicated via
said matrix.
[0019] In
accordance with another aspect, there is provided a hardware security module
comprising: two or more hardware ports, each one of which operable to
electronically
receive given input hardware port-specific cryptographic data thereon to
initiate execution
of an internal cryptographic process as a function thereof; two or more
segregated hardware
port-specific storage spaces each operatively linked to a corresponding one of
said
hardware ports via a corresponding hardware link, and storing respective
secured hardware
port-specific cryptographic data thereon exclusively retrievable as a function
of said given
input hardware port-specific cryptographic data corresponding thereto; and a
cryptographic
engine operable to execute said cryptographic process based on said secured
port-specific
6
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
cryptographic data retrieved from said segregated hardware port-specific
storage media as
a function of said given input port-specific cryptographic data.
[0020] In
one embodiment, each of said segregated hardware port-specific storage
media comprise distinctly embedded storage media operatively hardwired to said
corresponding one of said hardware ports.
[0021] In
one embodiment, each of said segregated hardware port-specific storage
media comprises distinct partitions of a common embedded storage media each
operatively
hardwired to said corresponding one of said hardware ports.
[0022] In
one embodiment, the hardware security module further comprises an
embedded processing system operable to execute said cryptographic engine.
[0023] In
one embodiment, the embedded processing system comprises a dedicated
processing core.
[0024] In
one embodiment, the hardware ports, said segregated hardware port-specific
storage media and said cryptographic engine are hardwired within a common
integrated
circuit architecture.
[0025] In
one embodiment, the common integrated circuit architecture is implemented
in a field-programmable gate array (FPGA).
[0026] In
one embodiment, a same said cryptographic engine is commonly operable to
execute a same said cryptographic process for each of said secured port-
specific
cryptographic data irrespective of hardware port-specificity.
[0027] In
one embodiment, the cryptographic engine comprises distinct hardware port-
specific cryptographic engines.
[0028] In
one embodiment, each of said distinct hardware port-specific cryptographic
engines is associated with a corresponding one of said segregated hardware-
port specific
storage spaces.
7
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0029] In
one embodiment, the corresponding one of said segregated hardware-port
specific storage spaces is exclusively accessible via a hardware link
operatively defined
through said associated one of said distinct hardware port-specific
cryptographic engines.
[0030] In
one embodiment, the hardware security module further comprises a
hardwired port interconnection (i.e. trusted communication) matrix that
operatively
interconnects at least some of said hardware ports in accordance with
predefined hardwired
port-specific logic.
[0031] In
one embodiment, the interconnection matrix is reconfigurable to redefine
said hardwired port-specific logic.
to [0032]
In one embodiment, the port interconnection matrix is further configured to
invoke one or more embedded communication channel resources operable on
selected
hardware port-specific data communicated via said matrix.
[0033] In
one embodiment, the one or more communication channel resources
comprise an inline channel encryption resource executed distinctly from said
cryptographic
engine.
[0034] In
one embodiment, the cryptographic engine is operable to execute a control
plane cryptographic process, whereas said inline channel encryption resource
is operable
to execute a communication plane cryptographic process subsequent to
successful
execution of said control plane cryptographic process.
[0035] In one embodiment, the control plane cryptographic process comprises
a new
session initiation process invoking a private key stored in said segregated
port-specific
storage space, whereas said communication plane cryptographic process
comprises an in-
session cryptographic process invoking a distinct session key.
[0036] In
one embodiment, the one or more communication channel resources
comprise at least one of an inline channel cryptographic resource, a data
channel diode
resource, a data channel filter resource, a data channel comparator resource,
and a data
channel sniffer resource.
8
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0037] In one embodiment, the module is a single-chip module.
[0038] In one embodiment, at least some said corresponding hardware link
is
implemented via common embedded hardware logic.
[0039] In one embodiment, the two or more segregated hardware port-
specific storage
spaces comprise one or more externally integrated hardware storage resources.
[0040] In one embodiment, the one or more communication channel
resources
comprise a trusted metering function. In one such embodiment, the trusted
metering
function is operable to track transactions (data, events, requests)
communicated on a given
hardware channel and output cryptographically authenticated metering messages
to accordingly.
[0041] In one embodiment, the one or more communication channel
resources
comprise a trusted flow control function. In one such embodiment, the trusted
flow control
function is operable to apply cryptographically authenticated flow control
restrictions on
transactions (data, events, requests) communicated on a given hardware
channel.
[0042] In one embodiment, the one or more communication channel resources
comprise a trusted function expander, wherein a data transaction relayed or
triggered on a
given input hardware channel is securely distributed and synchronized across
multiple
output hardware channels.
[0043] In one embodiment, the one or more communication channel
resources
comprise a trusted controllable event counter. In one such embodiment, the
trusted
controllable event counter is operable to apply cryptographically
authenticated control over
a designated event counting threshold thereof such that a trigger invoked upon
reaching
said threshold is securely adjustable. In one further such embodiment, the
trusted
controllable event counter is operatively associated with an onboard clock
frequency signal
to securely adjust output timing data associated therewith.
[0044] In accordance with another aspect, there is provided a single-
chip hardware
security module comprising: two or more hardware ports, each one of which
operable to
9
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
electronically receive given input hardware port-specific cryptographic data
thereon to
initiate execution of an internal cryptographic process as a function thereof;
two or more
segregated hardware port-specific storage media spaces each operatively linked
to a
corresponding one of said hardware ports via a corresponding hardware link,
and storing
respective secured hardware port-specific cryptographic data thereon
exclusively
retrievable as a function of said given input hardware port-specific
cryptographic data
corresponding thereto; and a cryptographic engine operable to execute said
cryptographic
process based on said secured port-specific cryptographic data retrieved from
said
segregated hardware port-specific storage media as a function of said given
input port-
specific cryptographic data.
[0045] In
one embodiment, each of said segregated hardware port-specific storage
media comprise distinctly embedded storage media operatively hardwired to said
corresponding one of said hardware ports.
[0046] In
one embodiment, the single-chip hardware security module further
comprises an embedded processing system operable to execute said cryptographic
engine.
[0047] In
one embodiment, the module is implemented in a field-programmable gate
array (FPGA).
[0048] In
one embodiment, the single-chip hardware security module further
comprises a hardwired port interconnection matrix that operatively
interconnects at least
some of said hardware ports in accordance with predefined hardwired port-
specific logic.
[0049] In
one embodiment, the interconnection matrix is (dynamically) reconfigurable
to redefine said hardwired port-specific logic.
[0050] A
further or distinct need exists for an integrated multi-level network security
appliance and system, that overcome some of the drawbacks of known techniques,
or at
least, provides a useful alternative thereto. Some aspects of this disclosure
also provide
examples of such systems and methods.
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0051] In
accordance with another aspect, there is provided a cross-domain network
traffic management appliance comprising: an external hardware network domain
port to
interface with an external network corresponding with a first network security
domain, and
exchange domain-specific data therethrough; a cross-domain hardware port to
interface
with a second network security domain and exchange cross-domain data
therethrough; one
or more hardware-integrated processing engines; and a hardware-integrated
interconnection matrix configured to define, in hardware, designated data
communication
paths to interconnect said processing engines; wherein said one or more
hardware-
integrated processing engines are operable to: process and validate ingress
first domain
data received from said first network security domain via said external
hardware port for
cross-domain egress via said cross-domain hardware port; and process cross-
domain
ingress data received via said cross-domain hardware port for dispatch to said
first network
security domain via said external hardware network port; wherein cross-domain
egress and
ingress data is internally encrypted and decrypted, respectively, in
accordance with a
.. designated destination-domain encryption process.
[0052] In
one embodiment, the cross-domain egress and ingress data is respectively
encrypted or decrypted by a hardware-integrated encryption engine.
[0053] In
one embodiment, the hardware-integrated encryption engine is operatively
associated with a plurality of hardware security module (HSM) ports distinctly
addressable
via said respective hardware paths of said interconnection matrix to
respectively encrypt
said cross-domain egress data and decrypt said cross-domain ingress data.
[0054] In
one embodiment, respective hardware paths of said interconnection matrix
physically segregates ingress and egress cross-domain data paths.
[0055] In
one embodiment, the appliance further comprises a distinctly addressable
hardware-integrated administrative engine operable to securely manage
operation of said
two or more hardware-integrated processing engines.
[0056] In
one embodiment, the appliance further comprises an external hardware
security network port distinctly addressable by one of said hardware-
integrated processing
11
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
engines to invoke an external validation process to be applied to said ingress
domain-
specific data prior to encryption for cross-domain egress.
[0057] In
one embodiment, said hardware-integrated processing engines comprise a
domain-specific protocol adapter operable to interface with said external
network domain
port, a cross-domain data validation engine operable to validate said ingress
domain-
specific data once processed by said protocol adapter, and a cross-domain
access portal
operable to interface with said cross-domain hardware port.
[0058] In
one embodiment, said interconnection matrix defines a one-way hardware
data path between said protocol adapter and said cross-domain access portal
via said cross-
domain data validation engine to process said ingress first domain data, and a
distinct
hardware data path between said cross-domain access portal and said protocol
adapter to
process said cross-domain ingress data.
[0059] In
one embodiment, said cross-domain hardware port comprises an external
cross-domain port to be operatively interfaced with a corresponding external
cross-domain
hardware port of a corresponding cross-domain network traffic management
appliance
operatively associated with said second network security domain.
[0060] In
one embodiment, said cross-domain hardware port comprises an internal
cross-domain port operatively interfacing with a corresponding internal cross-
domain
hardware port operatively associated with said second network security domain.
[0061] In one embodiment, said cross-domain hardware port is configured to
operatively interface with a secure interconnection network operatively
interconnecting
respective cross-domain hardware ports associated with respective network
security
domains to securely transfer encrypted cross-domain data therebetween.
[0062] In
one embodiment, said cross-domain hardware port is operable to interface
with multiple distinct second network security domains and exchange distinct
destination
domain-specific data therewith.
12
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0063] In
accordance with another aspect, there is provided a cross-domain network
traffic management system comprising: a plurality of hardware data path
layers, each one
of which corresponding with a designated network security domain and
comprising: an
external hardware network domain port to interface with an external network
corresponding with a given network security domain, and exchange domain-
specific data
therethrough; a cross-domain hardware port to interface with distinct hardware
data path
layers corresponding with distinct network security domains and exchange cross-
domain
data therethrough; one or more hardware-integrated processing engines; and a
hardware-
integrated interconnection matrix configured to define, in hardware,
designated data
communication paths to interconnect said processing engines; wherein said
hardware-
integrated processing engines are operable to: process and validate ingress
given domain
data received from said given network security domain via said external
hardware port for
cross-domain egress via said cross-domain hardware port; and process cross-
domain
ingress data received via said cross-domain hardware port for dispatch to said
given
network security domain via said external hardware network port; wherein cross-
domain
egress and ingress data is internally encrypted and decrypted, respectively,
in accordance
with a respectively designated destination-domain encryption process.
[0064] In
one embodiment, each said cross-domain hardware port operatively
interfaces with a secure interconnection network to securely transfer
encrypted cross-
domain data thereon.
[0065] In
accordance with another aspect, there is provided a multi-zone network
traffic management system or appliance comprising: one or more hardware-
integrated
processing engines operable to implement one or more network security
management
processes associated with a respective network security zone; and a trusted
hardware
interconnection matrix having a plurality of hardware ports associated
therewith and
configured to define in hardware multiple data communication paths embedded
therein
exclusively interconnecting said network security zones via respective
hardware paths
thereof that integrally invoke, in hardware, said network security management
processes;
wherein a given data transaction is routed in hardware via a designated
hardware path of
said interconnection matrix to operatively invoke a given network security
management
13
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
process, upon successful execution of which, said given data transaction is
successfully
relayed to a distinct zone via a distinct one of said hardware paths, such
that said network
security process is integrally invoked in hardware to process network
transactions between
said zones.
[0066] In one embodiment, said network security management processes
comprise a
transaction auditing process.
[0067] In
one embodiment, said given network transaction is relayed, encrypted, to
said distinct zone, and only successfully decrypted therein upon successful
execution of
said given network security management process.
to [0068]
In one embodiment, said security management process, upon successful
execution thereof, releases a decryption key to successfully decrypt said
relayed network
transaction.
[0069] In
one embodiment, said given network security management process, upon
successful execution thereof, locally decrypts said given network transaction
to be relayed
to said distinct zone accordingly.
[0070] In
one embodiment, said one or more network security management processes
comprise a cryptographic process; and said one or more hardware-integrated
processing
engines comprise a cryptographic engine hardwired to interface with said
hardware ports
to execute each said cryptographic process.
[0071] Other aspects, features and/or advantages will become more apparent
upon
reading of the following non-restrictive description of specific embodiments
thereof, given
by way of example only with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE FIGURES
[0072]
Several embodiments of the present disclosure will be provided, by way of
examples only, with reference to the appended drawings, wherein:
14
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0073]
Figure 1 is a schematic diagram of a hardware security module (HSM), in
accordance with one embodiment;
[0074]
Figure 2 is a schematic diagram of a hardware security module (HSM), in
accordance with another embodiment;
[0075] Figure 3A is a schematic diagram of a hardware security module
(HSM), in
accordance with yet another embodiment;
[0076]
Figure 3B is a schematic diagram of a hardware security module (HSM), in
accordance with yet another embodiment;
[0077]
Figure 3C is a schematic diagram of a hardware security module (HSM), in
1() accordance with yet another embodiment;
[0078]
Figure 4 is a schematic diagram of an integrated security processing system
integrating a multi-level HSM interfacing via respective hardware connections
with a series
of associated processing engines, in accordance with one embodiment;
[0079]
Figure 5 is a schematic diagram of a network security zoning architecture for
a
secure application invoking various network security zones, in accordance with
one
embodiment;
[0080]
Figure 6 is a schematic diagram of a network security zoning architecture,
such
as that illustrated in the embodiment of Figure 5, deployed within the context
of the secured
integrated system or appliance illustrated in Figure 4;
[0081] Figure 7 is a schematic diagram of an exemplary multi-port
distribution
function for a secure application, in accordance with one embodiment;
[0082]
Figures 8A and 8B are schematic diagrams of a trusted metering and trusted
flow control function, respectively, for a secure application, in accordance
with one
embodiment;
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0083]
Figure 9 is a schematic diagram of a trusted controllable frequency function
for
a secure application, in accordance with one embodiment;
[0084]
Figure 10 is a schematic diagram of an integrated multi-level network
appliance, in accordance with one embodiment, having a trusted communication
matrix or
intelligent switch embedded therein, and optionally having one or more
embedded channel
resources accessible thereto;
[0085]
Figure 11 is a schematic diagram of an embedded hardware security module
(HSM) operable as a trusted intelligent switch in the integrated multi-level
network
appliance of Figure 10, in which embedded HSM security resources are provided
as an
optional embedded channel resource, in accordance with one embodiment;
[0086]
Figure 12A is a schematic diagram of an embedded hardware security module
(HSM) operable as a trusted intelligent switch in the integrated multi-level
network
appliance of Figure 10, in which embedded HSM security resources are provided
as an
optional embedded channel resource, and in which additional channel resources
are also
optionally provided, in accordance with another embodiment;
[0087]
Figure 12B is a schematic diagram of an embedded hardware security module
(HSM) operable as a trusted intelligent switch, in accordance with yet another
embodiment;
[0088]
Figure 12C is a schematic diagram of an embedded hardware security module
(HSM) operable as a trusted intelligent switch, in accordance with yet another
embodiment;
[0089] Figure 13 is a schematic diagram of the embedded HSM of Figure 12A
once
integrated within the appliance of Figure 10 thereby acting both as an
intelligent switch
and as a multi-level HSM that interfaces via respective hardware connections
with a series
of associated appliance processing engines, in accordance with one embodiment;
[0090]
Figure 14 is a schematic diagram of a network security zoning architecture for
a secure application invoking various network security zones, in accordance
with one
embodiment;
16
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0091]
Figure 15 is a schematic diagram of a network security zoning architecture,
such
as that illustrated in the embodiment of Figure 14, deployed within the
context of the
integrated appliance illustrated in Figure 13;
[0092]
Figure 16 is a schematic diagram of a combined Entropy as a Service (EaaS)
and Time Service system, as implemented within a single security processing
appliance
and in accordance with one embodiment, for providing accurate time-stamps and
entropy
data to client systems;
[0093]
Figure 17 is a schematic diagram of a Smart Data Diode, as implemented within
a single security processing appliance and in accordance with another
exemplary
embodiment, for efficiently and securely isolating network traffic originating
from outside
a trusted network (the egress) from network traffic originating from inside
the trusted
network (the ingress);
[0094]
Figures 18 to 20 are schematic diagrams of exemplary embodiments of a
Trusted Data Guard system executable within the context of a single security
processing
appliance, for separating an Egress traffic flow from an Ingress traffic flow,
and for each
implementing a series of inline validation and sanitizing functions;
[0095]
Figure 21 is a schematic diagram of a dual-layer Virtual Private Network (VPN)
system executable within the context of a single security processing
appliance, in
accordance with one embodiment;
[0096] Figure 22 is a schematic diagram of a trusted auditing system
executable within
the context of a single security processing appliance, in accordance with one
embodiment;
[0097]
Figure 23 is a schematic representation of a Cross-Domain Solution (CDS)
enforcement point based on one or more security processing appliances (SPAs)
configured
in a CDS mode of operation (SPA-CDS), in accordance with one embodiment;
[0098] Figure 24 is a schematic representation of three separate network
interfaces of
an illustrative SPA-CDS, in accordance with one embodiment; and
17
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[0099]
Figures 25A to 25C are schematic representations of a Universal Cyber Security
Platform (UCSP) or SPA configured as an exemplary implementation of the SPA-
CDS of
Figures 23 and 24, in accordance with one embodiment.
[00100] Elements in the several figures are illustrated for simplicity and
clarity and have
not necessarily been drawn to scale. For example, the dimensions of some of
the elements
in the figures may be emphasized relative to other elements for facilitating
understanding
of the various presently disclosed embodiments. Also, common, but well-
understood
elements that are useful or necessary in commercially feasible embodiments are
often not
depicted in order to facilitate a less obstructed view of these various
embodiments of the
1() present disclosure.
DETAILED DESCRIPTION
[00101] Various implementations and aspects of the specification will be
described with
reference to details discussed below. The following description and drawings
are
illustrative of the specification and are not to be construed as limiting the
specification.
Numerous specific details are described to provide a thorough understanding of
various
implementations of the present specification. However, in certain instances,
well-known or
conventional details are not described in order to provide a concise
discussion of
implementations of the present specification.
[00102] Various apparatuses and processes will be described below to provide
examples
of implementations of the system disclosed herein. No implementation described
below
limits any claimed implementation and any claimed implementations may cover
processes
or apparatuses that differ from those described below. The claimed
implementations are
not limited to apparatuses or processes having all of the features of any one
apparatus or
process described below or to features common to multiple or all of the
apparatuses or
processes described below. It is possible that an apparatus or process
described below is
not an implementation of any claimed subject matter.
[00103] Furthermore, numerous specific details are set forth in order to
provide a
thorough understanding of the implementations described herein. However, it
will be
18
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
understood by those skilled in the relevant arts that the implementations
described herein
may be practiced without these specific details. In other instances, well-
known methods,
procedures and components have not been described in detail so as not to
obscure the
implementations described herein.
[00104] In this specification, elements may be described as "configured to"
perform one
or more functions or "configured for" such functions. In general, an element
that is
configured to perform or configured for performing a function is enabled to
perform the
function, or is suitable for performing the function, or is adapted to perform
the function,
or is operable to perform the function, or is otherwise capable of performing
the function.
[00105] It is understood that for the purpose of this specification,
language of "at least
one of X, Y, and Z" and "one or more of X, Y and Z" may be construed as X
only, Y only,
Z only, or any combination of two or more items X, Y, and Z (e.g., XYZ, XY,
YZ, ZZ, and
the like). Similar logic may be applied for two or more items in any
occurrence of "at least
one ..." and "one or more..." language.
[00106] The systems, devices and methods described herein provide, in
accordance with
different embodiments, different secure network hardware solutions, for
instance, such as
a trusted hardware network interconnection device (matrix), that can be
utilized, alone or
in combination with an integrated HSM, to provide various trusted network
interconnection
resources, services and/or solutions.
[00107] As noted above, the systems and methods described herein also provide,
in
accordance with different embodiments, different examples in which a hardware
security
module (HSM) is operable to concurrently service multiple applications and/or
functions
while minimizing system security risks that may otherwise be introduced when
interfacing
with a traditional HSM via an intermediary HSM access appliance, application
layer or
HSM access software.
[00108] For instance, in some embodiments, the HSM comprises a plurality of
hardware
ports, each one configured or reconfigurable to receive input (e.g. public
data, public key,
etc.) thereon to execute a designated cryptographic process within the HSM in
servicing a
19
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
particular computational process, application or function. In general,
received input data
will be port-specific in that only input cryptographic data specific to the
port on which it is
received can be successfully processed. To do so, each hardware port will
generally have
defined in association therewith a corresponding hardware link or channel
(e.g. static
and/or reconfigurable hardware link, channel and/or switch) to a segregated
hardware
storage media that stores secured port-specific cryptographic data thereon
exclusively
retrievable for processing as a function of received input data specific to
that hardware port.
For example, distinct embedded storage resources may be provided with
respective
hardware data links to their corresponding port, as can distinct storage
partitions and/or
zones be defined within a same embedded memory storage resource and accessed
via
dedicated hardware logic or the like. Namely, distinct embedded storage spaces
or
resources may encompass a physically segregated, separated and/or defined
hardware
storage space on one or more hardware storage devices (i.e. memory board,
chip,
component, etc.) that is physically paired, allocated and/or associated with a
given port-
specific cryptographic process. Each storage space may be designated or
adapted to store
one or more cryptographic keys and/or like cryptographic data usable in
invoking and/or
executing a given port-specific process. Accordingly, in some embodiments, a
dedicated
memory space may define a secure key space for a given cryptographic process
and/or
encompass storage capacity for other types of cryptographic and/or other
related data. An
integrated cryptographic engine, executed by an embedded or hardware linked
processor,
can then be invoked to internally process the retrieved secured cryptographic
data, for
instance in conjunction with the input data, to produce an intended
computation result.
[00109] Accordingly, the entire process can be relegated to the hardware space
without
invoking a software or application layer and thus, without opening the HSM to
tampering
opportunities that may otherwise present themselves in conventional HSMs, such
as
traditional network-attached HSMs. Conversely, the HSM embodiments described
herein
allow for a full, and in some embodiments a single-chip (i.e. static or
reconfigurable (e.g.
FPGA)) hardware solution that can be used to concurrently service multiple
applications
and/or processes from within a same tamper-resistant environment. Accordingly,
the
solutions provided herein may allow for a significant increase in security
protocol ratings
while also significantly reducing, in some embodiments, the hardware footprint
required
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
to implement complex network security architectures that, in most cases, would
require the
co-location of multiple distinctly executed HSMs internetworked with various
external
devices in a complex cabled architecture. Further illustrative details,
examples, advantages
and features will be described below with reference to exemplary embodiments.
.. [00110] With reference to Figure 1, and in accordance with one exemplary
embodiment,
a hardware security module (HSM), generally referred to using the numeral 100,
will now
be described. In the illustrated embodiment, the HSM 100 generally comprises a
plurality
of hardware ports 102 each operatively linked through hardware, e.g. direct
hardware link
or channel logic 108, to a corresponding port-specific hardware storage
resource and key
1() space 104 (e.g. distinct embedded memory storage device, hardware
memory storage
partition and/or zone). Each storage resource 104 can be configured to store
secured port-
specific cryptographic data (e.g. private encryption/decryption key 112) that
is only
retrievable upon input of corresponding input cryptographic data from a
corresponding
port. In other ports, secured data may be further secured by virtue of
hardware port
specificity, whereby input data received on an incorrect hardware port will
fail to access
corresponding secured data linked to this incorrect port, and also fail to
access secured data
linked with any other port.
[00111] Upon successful input of external data via an appropriate hardware
port 102,
corresponding secured data (e.g. key 112) can be internally retrieved and
processed by an
integrated engine (i.e. cryptographic engine 110) to deliver a desired
outcome.
[00112] To further enhance anti-tampering measures, in some embodiments, the
HSM
100 may be enclosed within a tamper-proof or resistant box, container or shell
106.
[00113] As noted above, the provision of hardware-linked HSM ports and
segregated
storage resources enhances overall system integrity and resilience to external
tampering,
while also providing the added benefit of HSM multiplicity within a common
tamper-
resistant shell. In fact, certain embodiments may efficiently multiply HSM
resource
allocations within a single chip implementation, e.g. with embedded
memory(ies),
processor(s) and hardware logic, while leveraging both the added security of
distinctly
segregated hardware-linked storage resource interfaces and the option to share
internal
21
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
hardware resources, such as a common integrated cryptographic engine 110 that
may be
invoked to concurrently or at least sequentially process secured data from
multiple isolated
key spaces 104. As will be described in further detail below, this integrated
hardware
implementation may further benefit the deployment of integrated secure system
architectures, such as multi-level security system architectures and the like,
all within the
confines of a single hardware casing or shell, if not integrated onto a
singular circuit board
in some embodiments.
[00114] With reference to Figure 2, and in accordance with another embodiment,
a HSM
200, much as described above with reference to Figure 1, will now be
described. In this
1()
embodiment, the HSM 200 again generally comprises a plurality of hardware
ports 202
each operatively linked through hardware to a corresponding port-specific
hardware
storage resource and key space 204, in which secured port-specific
cryptographic data 212
can be stored and securely retrieved to execute one or more cryptographic
processes via an
integrated engine 210.
[00115] In this embodiment, however, at least some of the hardware ports 202
can be
linked through hardware to interface with distinct storage resources 204
and/or ports 202,
and/or processes/data associated therewith, thereby defining a trusted
communication (e.g.
hardwired port interconnection) matrix 214 that can be leveraged in more
complex system
implementations to benefit from the secured co-location of distinct resources
on a same
hardware implementation (e.g. same hardware chip) without exposing the HSM 200
to
external or software-related tampering risks. In other words, port-specificity
can be
maintained to govern access to secured data in executing selected
cryptographic processes,
as described above with reference to Figure 1, but further enhanced by
leveraging
predefined hardware interconnections (i.e. data channels) between port-
specific resources
and/or data allocations. The trusted communication matrix 214 can be
implemented as a
set of static hardware relays and/or logic, and/or dynamically implemented via
reconfigurable hardware logic and/or relays. Accordingly, certain port-
specific processes
invoked by input data received via a particular port interface may be
configured to depend
from upstream cryptographic processes executed in respect of cryptographic
data received
on another hardware port and used to retrieve distinctly stored and maintained
private data.
22
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
Naturally, certain cryptographic processes may equally feed downstream
processes
executed in respect of a distinct port-specific data resource. Given the
hardware
implementation of the matrix 214, system security logic and complex data
channeling can
be hardwired into the HSM 200 and thus minimize external exposure to
tampering. Given
the above, it will be appreciated that while some ports 202 may be associated
with
corresponding storage resources 204 in a one-to-one fashion, other port
interconnection
scenarios may be invoked to logically associate a same port with distinct
storage resources,
as can distinct storage resources may be logically associated with a same
hardware port.
Likewise, additional hardware port interfaces may be defined to execute
certain channel
interconnection configurations without necessarily forming a direct link with
any particular
storage resource, for example.
[00116] As will be described in greater detail below, such variability and
customizability may allow for the deployment and execution of different
trusted hardware
network interconnection solutions, such as for example, in linearly channeling
port-specific
data transactions between hardware ports in one or more one-to-one hardware
port
interconnection configurations (e.g. to provide (cryptographically)
secure/trusted
hardware-segregated port-specific processing paths), in consolidation/merging/
multiplexing distinct data channels inbound via distinct hardware ports in a
many-to-one
configuration (e.g. to provide (cryptographically) secure/trusted
data/transaction
convergence processing paths), and/or in distributing and/or demultiplexing a
single
network source across multiple port-specific resources, services and/or data
communication paths in parallel in a one-to-many configuration (e.g. to
provide
(cryptographically) secure/trusted data/transaction distribution/dissemination
across
multiple data channels from a trusted/reliable source).
[00117] In accordance with different illustrative embodiments, different non-
limiting
examples of single-chip hardware solutions may be considered. In some
embodiments, a
Xilinx's System on Chip (SoC) or Multi-Purpose SoC (1\SPSoC) product may be
used, such
as Zynq and Zynq UltraScale+TM respectively. The Zynq product line is known
to
contain 2 ARM processors, memory components and Field Programmable Gate Array
(FPGA) while the Zynq UltraScale+TM has 6 ARM processors, memory components
and
23
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
FPGA. In a first exemplary embodiment, the Zynq device may be used wherein
one of
the two ARM processors implements the cryptographic engine (CE) 201, a second
ARM
processor handles all memory accesses and the FPGA implements the trusted
communication matrix 214 between external communication ports and internal
memory
and cryptographic engine capability. In a second exemplary embodiment, the
Zynq
UltraScale+TM is used wherein 5 of the 6 ARM processors are used as
independent CEs
while the sixth processor is used for handling all memory accesses and the
FPGA
implements the trusted communication matrix 214 between the external
communication
ports, internal memory and cryptographic engine capability. In a third
exemplary
embodiment, the Zynq UltraScale+TM is used where all of the 6 ARM processors
are
utilized as independent CEs managing their own memory space and the FPGA
implements
the trusted communication matrix 214 between the external communication ports,
internal
memory and cryptographic engine capability. Other known and future
technologies,
hardware configurations and products may also be considered, as will be
readily apparent
to the skilled artisan, without departing from the general scope and nature of
the present
disclosure.
[00118] With reference to Figure 3A, and in accordance with yet another
embodiment,
a HSM 300, much as described above with reference to Figures 1 and 2, will now
be
described. In this embodiment, the HSM 300 again generally comprises a
plurality of
hardware ports 302 each operatively linked through hardware to a corresponding
port-
specific hardware storage resource and key space 304, in which secured port-
specific
cryptographic data 312 can be stored and securely retrieved to execute one or
more
cryptographic processes via an integrated engine 310.
[00119] As with the embodiment of Figure 2, at least some of the hardware
ports 302
can be linked through hardware to interface with distinct storage resources
304 and/or ports
302, and/or processes/data associated therewith, thereby again defining a
trusted
communication matrix 314. The 314 can again be implemented as a set of static
hardware
relays and/or logic, and/or dynamically implemented via reconfigurable
hardware logic
and/or relays.
24
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00120] In this embodiment, however, the matrix 314 may further invoke certain
embedded channel resources 316 so to further enhance interconnection logic
between ports
and port-related processes, and thus allow for embedded security logic
integration within
the HSM' s integrated hardware architecture. These channel resources 316 may
be
integrated and invoked in a one-to-one fashion, for instance, with integrated
port specificity
in fully maximizing secure process isolation, or again provided as a shared
resource (one-
to-many and/or many-to-one) that may be invoked and implemented for different
port-
specific processes albeit without exposing any such processes to undue
external tampering
risks.
[00121] In the illustrated embodiment, different channel resources are
schematically
illustrated to include any one or more of a data channel diode 318 (i.e. to
restrict data flows
on a defined channel to a designated direction), data channel filter 320 (i.e.
to filter channel
data, for example, to limit throughput data to a particular subset of
retrieved data, or again
to systematically reconfigure or replace designated data elements on a given
channel data
path), a channel comparator 322 (i.e. to invoke channel logic between channels
based on a
comparison of data being channeled thereon, for example, allowing process
throughput
only upon matching channel data), an inline encryption function 324 (e.g. to
execute inline
IPSEC or TLS protocol, for example, and/or to implement an inline VPN or like
communication tunnel), or sniffer function (325).
[00122] For example, in some embodiments, an inline encryption function may be
invoked to facilitate certain encrypted exchange with an end client or
application that do
not necessarily require access to the cryptographic engine and related higher
security
protocols. For instance, while critical private key management processes (e.g.
control plane
processes such as user/client authentication/authorization, authenticated
session initiation
and configuration, private key generation and management, system management
functions,
etc.) may be strictly relegated to the cryptographic engine and defined secure
key spaces,
less critical processes (e.g. communication plane processes, such as
authenticated data
access transactions, updates, edits, etc.,) for instance executed on the basis
of a symmetric
and/or ephemeral (e.g. session) key used to expedite processing and
communications, may
be implemented via the inline channel encryption resource 324. In so doing,
the HSM 300
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
may integrally combine enhanced control plane cryptographic services, as
described above,
with inline cryptographic services, all within a same hardware design and
configuration.
This may, for example, readily allow for a singular hardware design, as
described herein,
to replace an otherwise common network (e.g. banking) architecture in which
control plane
functions and processes are traditionally relegated to a distinct network
interfacing HSM,
while session-based cryptographic functions are subsequently channeled through
downstream network servers. The integrated configuration discussed herein may
further,
or alternatively, allow for the integrated execution of a virtual private
network (VPN) or
even nested VPNs to achieve a layered architecture within a single hardware
design rather
1() than to invoke a distributed network architecture in which security
protocols are otherwise
run on a higher network (e.g. TCP/IP) layer, and thus, more vulnerable to
physical or
external tampering.
[00123] As noted above, a sniffer or like function may also, or alternatively
be deployed
as an integrated and/or customizable channel resource, for instance, to
provide a silent non-
bypassable logging or network/channel tapping function to gain visibility on
network
channel communications. For instance, such channel resources may be non-
obstructively
used to monitor channel communications and raise a flag or alert upon
identifying
suspicious or anomalous channel activity, if not shutting down outright
communications
on this channel until remedial action can be taken.
[00124] As noted above, a trusted comparator or like function may be included
to merge
or otherwise compare data streams on respective hardware channels to increase
a security
and/or reliability thereof. Likewise, and as also noted above, a
demultiplexing or multi-
port distribution function (e.g. trusted function expander) may be implemented
to securely
distribute a same data stream or transaction across multiple hardware port-
specific
channels. For example, different applications may require for identical data
to be
distributed in parallel between data channels while ensuring an accuracy and
reliability of
the data source. Accordingly, by having such data originate or result from a
secure process
internal to the hardware interconnection device and/or integrated HSM, as
described
herein, secure replication and parallel distribution of such data across
multiple embedded
hardware data channels can be reliably executed.
26
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00125] With reference to Figure 7, and in accordance with one embodiment, an
exemplary multi-port distribution function, generally referred to using the
numeral 700 will
now be described. In this exemplary embodiment, an incoming event/data
transaction/process 705 is received via an embedded hardware port-specific
data channel
of hardware interconnection device and/or integrated HSM 707. Event 705 is
split into a
multiplicity of identical events 707, each comprising the exact same data
content as the
original event 705; wherein each event is processed by its own critical logic
function 707.
Each critical logic function leverages the embedded hardware to realize a
synchronization
process 711, wherein the multiplicity of events/processes are all synchronized
upon exiting
hardware interconnection device and/or integrated HSM 707 on their own
embedded port-
specific hardware data channels 715.
[00126] Examples of multi-channel data distribution applications may include,
but are
not limited to, the secure distribution of a synchronized network time stamp
or clock (for
example, in the management or maintenance of highly synchronized network
resources),
which trusted time can originate from a single trusted resident high precision
timing device
(e.g. see timing device 444 of Figure 4) based on resident and/or accessible
high precision
atomic clock cycles and/or applicable GPS time data, for example. Using the
secure
centralized hardware architecture of a particular network interconnection
matrix as
described herein, identical time stamps or like data packets/details (e.g.
headers, payload,
flags, tags, etc.) may be securely, accurately and reliably distributed across
multiple
hardware (port-specific) data channels, in parallel at the same time (e.g.
reliable, monitored
distribution time) and while minimizing possible data tampering/alterations
between ports.
[00127] Following from the above-noted time distribution example, another
application
that may extend therefrom includes the provision of reliable distributed time
smearing
between multiple hardware-port specific resources, such as for example, across
a large
network of interconnected network resources each ultimately relying on a
central reliable
time source, such as that illustratively provided by the resident high
precision timing device
of the herein-described embodiments. In this particular example, UTC leap
seconds can be
progressively smeared over a designated time period prior to and/or after
(e.g. 6, 12 or 24
hours before/after) a particular UTC leap second is to take effect, thereby
effectively
27
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
smearing the temporal impact of the leap second over such time period to avoid
an
instantaneous jump or gap, provided such smearing is equally applied to all
related network
devices. Using an embodiment of the secure network device/appliance described
herein,
effective time smearing can be securely, reliably and identically applied to a
number of
interconnected network resources provided such resources are configured to
uniformly rely
on the central time smearing functionality of the appliance. To do so, the
hardware
implemented multi-channel data distribution technique described above can be
used to
reliably source the internal clock cycles and/or UTC time credentials of the
appliance to
define accurate time and/or time smearing references (e.g. by temporarily
reducing/increasing atomic clock cycle counts to accommodate for one or more
leap
seconds to be applied at a designated time) and uniformly distribute such time
references
in parallel across multiple hardware-port specific resources while minimizing
tampering
and/or mis-synchronization risks. Likewise, for example within the context of
a multi-level
network or appliance interfacing with distinct security zones/levels,
synchronized time
and/or smearing may be reliably and securely distributed across multiple zones
simultaneously. In yet another example, the interconnection matrix may also or
alternatively include one or more channel traffic metering and/or gating
functions. For
example, similar to the sniffer function described above, one or more hardware
channels
may include or be embedded with an inline resource to monitor and/or control a
flow of
data and/or transactions on this channel. For example, an active gating
function may
enforce a particular data/transaction gating schedule whereby certain data
transactions
invoking this hardware channel can only be executed at select times and/or
intervals (e.g.
once every minute, every few seconds, every hour, every day, etc.). This may
be applied,
for example, given a particular service model that only authorizes a certain
throughput of
transactions given a particular payment model, or again for a certain service
level. In other
examples, scheduled gating functions may rather or also be applied to enhance
security
protocols, whereby transaction and gating schedule synchronization is required
to
successfully execute a particular transaction or process (e.g. data access or
user
authentication only permitted at designated times or intervals), and whereby
unsynchronized access results in a block service/resource and/or flag to a
system
administrator.
28
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00128] Gating may also or alternatively include start/stop, duration,
frequency, volume
and/or duration metering thresholds, whereby accessed services are limited
based on
security thresholds (e.g. a sudden surge in activity raising security
concerns), service model
(e.g. payment model based on a number of transactions per unit time) and/or
security access
windows, to name a few examples.
[00129] With reference to Figures 8A, and in accordance with one embodiment, a
trusted metering function, to be implemented within the hardware
interconnection device
and/or integrated HSM described above, and generally referred to using the
numeral 800,
will now be described. In the exemplary embodiment of Figure 8A, a number of
discrete
.. incoming digital events, data, processes and/or service requests per unit
time 806 may be
tracked and/or monitored in a trusted fashion. As shown in Figure 8A, the flow
of discrete
data/events 806 entering and exiting hardware interconnection device and/or
integrated
HSM 809 via embedded hardware data channels is channeled through a trusted
flow meter
function 811, which is operable to measure said flow (number per unit time) of
incoming
events travelling through hardware interconnection device and/or integrated
HSM 809. The
measurement is sent to a secure counter function 815, which is operable to
produce and
record cryptographically authenticated status messages 817. Secure counter 815
cannot be
tampered with and the resulting count status messages 817 are strongly
authenticated by
the counting function. In this embodiment, the flow of data/events/requests is
not perturbed
but only monitored. In contrast, Figure 8B shows an exemplary embodiment of a
flow
control function provided for data flow control. In this exemplary embodiment,
a given
number of events and/or amount of data flow and/or processed events in a given
unit of
time may be controlled and/or enforced inside a trusted security boundary
provided by
hardware interconnection device and/or integrated HSM 809. A control interface
819 is
used to modify or manage this functionality via a set of cryptographically
authenticated
control messages 818 listing a set of conditions under which some of
events/data 806 are
allowed through the security boundary and exit via a secure data channel to
produce an exit
data/event flow 821.
[00130] Likewise, inline metering of one or more hardware data channels may
allow for
.. the provision of certain service models (e.g. fee per transaction and/or
per quantum of
29
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
transactions), and/or various management applications (e.g. monitor when/how
certain
cryptographic keys, port-specific resources are used, etc.)
[00131] With reference to Figure 9, and in accordance with one embodiment, a
trusted
controllable event counter, generally referred to using the numeral 900, will
now be
described. In this exemplary embodiment, the secure counting feature described
above may
be leveraged to alter and trigger an output response. As shown in Figure 9, an
incoming
event/data/process 905 is received via an embedded hardware data channel into
hardware
interconnection device and/or integrated HSM 907. Event/data/process 905 is
channeled
therefrom to a trusted counting logic function 909, which is operable to
measure/count the
flow or number of events/data/process 905 being received. This number and/or
flow of
received event/data/processes 905 may be compared via a comparator function
917 via
threshold register 921. Upon said threshold being reached, a Trigger signal
927 may be
outputted via a port specific hardware channel. The threshold register 921 may
be modified
via control interface 923, which is authenticated and verified via a set of
cryptographically
authenticated control messages 925.
[00132] The above described trusted controllable event counter may be used to
trigger
a one pulse-per-second (1PPS) output signal 927 by counting a stable clock
frequency as
the input signal 905 and allowing to modify the duration of the 1 PPS period
by modifying
the threshold register 921. An application that may extend therefrom, combined
with the
above-described multi-port distribution function, includes the provision of
reliable
distributed time smearing between multiple hardware-port specific resources,
such as for
example, across a large network of interconnected network resources each
ultimately
relying on a central reliable time source, such as that illustratively
provided by the resident
high precision timing device of the herein-described embodiments. In this
particular
example, UTC leap seconds can be progressively smeared over a designated time
period
prior to and/or after (e.g. 6, 12 or 24 hours before/after) a particular UTC
leap second is to
take effect, thereby effectively smearing the temporal impact of the leap
second over such
time period to avoid an instantaneous jump or gap, provided such smearing is
equally
applied to all related network devices. Using an embodiment of the secure
network
device/appliance described herein, effective time smearing can be securely,
reliably and
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
identically applied to a number of interconnected network resources provided
such
resources are configured to uniformly rely on the central time smearing
functionality of the
appliance. To do so, the hardware implemented multi-channel data distribution
technique
described above can be used to reliably source the internal clock cycles
and/or UTC time
credentials of the appliance to define accurate time and/or time smearing
references (e.g.
by temporarily reducing/increasing atomic clock cycle counts to accommodate
for one or
more leap seconds to be applied at a designated time) and uniformly distribute
such time
references in parallel across multiple hardware-port specific resources while
minimizing
tampering and/or mis-synchronization risks. Likewise, for example within the
context of a
multi-level network or appliance interfacing with distinct security
zones/levels,
synchronized time and/or smearing may be reliably and securely distributed
across multiple
zones simultaneously.
[00133] It will be appreciated that some or all, or again different channel
resources may
be integrated to provide different interconnection logic and functions between
port-specific
processes and thus enhance available internal process complexity and
flexibility in
providing a whole integrated solution, in some embodiments, embedded within a
singular
HSM chip implementation.
[00134] In this particular embodiment, the HSM 300 is further provided with
optional
external sensor monitors 326, for example, which may take the form of various
sensors
and/or monitors used to detect and report on system breaches or tampering. For
example,
sensors may include, but are not limited to, integrated sound sensors that may
detect shell
impacts or breaks; inclinometers or 3D accelerometers to detect displacement
or physical
reorientation of the shell; smoke, heat and/or water sensors to detect
environmental issues
and/or tampering (e.g. multiple temperature sensors can be used to detect
tampering via
differential internal temperature metering); proximity or motion sensors to
detect presence
of unauthorized personnel; location or geofencing sensors to detect
unauthorized transport
of the HSM beyond a designed security zone; and other such sensors as may be
appreciated
by the skilled artisan.
31
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00135] The HSM 300 may further include an administrator port 338, such as a
local
USB port or dedicated network port interface to allow for secured
administrative access to
the HSM 300 and allow for system maintenance and reconfiguration as may be
required or
desired from time to time. For example, where the HSM 300 is implemented as a
reconfigurable chip (e.g. FPGA), certain hardware resources and/or logic may
be re-
allocated or reconfigured to address system or security protocol changes or
improvements.
For example, the trusted communication matrix may be adjusted to reflect new
port
allocations or leverage new or existing channel resources to further enhance
security
protocols, introduce new security levels or system integrations, or again
refine existing
protocols with improved processes and functions.
[00136] In addition, HSM 300 may allow for software, firmware and/or FPGA
updates
through a secured validation process. This validation process may, in some
embodiments,
only accept validated inputs by means of administrative port 338 and/or
hardware ports
302 through a "chain of trust" process via digital signatures using quantum
safe algorithms,
such as hash-based signature algorithms.
[00137] As illustratively described above with reference to Figures 1 to 3A,
in some
embodiments, the HSM (100, 200, 300) may be configured to share a common
cryptographic engine (110, 210, 310), that is an embedded resources executing
one or more
cryptographic processed predefined in firmware and secured within the confines
of the
HSM' s hardware architecture. Accordingly, respective secured cryptographic
data (e.g.
private key data) can be respectively accessed and used by the common
cryptographic
engine from respective port-specific storage spaces (104, 204, 304) to render
secure HSM
functions to respective port-specific masters (e.g. users, clients,
applications, etc.)
[00138] With reference to Figure 3B, an alternative HSM configuration 300' is
rather
designed to define a respective cryptographic engine 310' for each of the
secured key
spaces 304'. By replicating cryptographic resources, further hardware
isolation (e.g.
distinct firmware resources and/or firmware executed on distinct embedded
processor
cores) can be achieved in thus further enhancing the HSM' s tamper resistance.
32
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00139] In yet another embodiment illustrated in Figure 3C, an alternative HSM
configuration 300" again replicates cryptographic resources 310" for each of
the defined
key spaces 304", but in this case, embeds these resources within the hardware
design so to
be invoked before access is granted to the respective port-specific key
spaces. This may be
particular useful in a context where, for example, storage resources used to
define the
respective key spaces are provided external to an otherwise embedded HSM chip.
In other
words, HSM resources may leverage an external storage resource such as a co-
located or
integrated flash drive or hard drive to store private key or other secured
cryptographic data
for exclusive access via embedded port-specific cryptographic engines. The
person of
ordinary skill in the art will appreciate that other configurations may also
be considered
without departing from the general scope and nature of the present disclosure.
[00140] Using different aspects of the above-described embodiments, complex
system
architectures may be deployed on a single chip, as noted above, or again on a
same
integrated board design, i.e. where an embedded multi-port HSM can be
integrated with
other system hardware on a same or interconnected circuit boards to deliver a
complex (e.g.
multi-purpose, multi-level, multi-tiered, multi-user, etc.) cryptographic
service and system
as a whole, all in some embodiments, within a same tamper-resistant shell.
[00141] With reference to Figure 4, and in accordance with one embodiment, an
integrated security processing system 400 will now be described, in which a
single-chip
HSM 401, much as described above with reference to Figure 3, is illustratively
integrated
to act as a multi-function HSM within the integrated system architecture of
system 400. In
this particular embodiment, the HSM 401 illustratively comprises a plurality
of hardware
ports 402 each operatively linked through hardware to a corresponding port-
specific
hardware storage resource and key space 404, in which secured port-specific
cryptographic
data 412 can be stored and securely retrieved to execute one or more
cryptographic
processes via an integrated engine 410. Again, hardware ports 402 can be
linked through
hardware to interface with distinct storage resources 404 and/or ports 402,
and/or
processes/data associated therewith, to define a port trusted communication
matrix 414.
The port trusted communication matrix 414 can again be implemented as a set of
static
hardware relays and logic, and/or dynamically implemented via reconfigurable
hardware
33
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
logic or relays. Embedded channel resources 416 are also optionally provided
to further
enhance interconnection logic between ports and port-related processes.
[00142] Integrated with the HSM 401 are provided distinct processing resources
440
that may be configured to execute various system processes that rely, at least
in part, on
the cryptographic outputs of the HSM 401, and/or contribute inputs to the HSM
401 to be
processed in respect of one or more downstream processes. Generally, these
processing
resources 440 will include one or more processing engines and storage media
encoding
various machine executable tasks and instructions to be processed thereby, for
example,
via one or more accessible processors or the like. Accordingly, a secure data
path may be
internally routed from one processing engine 440 to the other via the
integrated HSM 401,
in some embodiments, either internally hardwired via internal cabling or
direct circuit
board interconnections, so to effectively execute multi-level or multi-
function data security
system integration within a wholly integrated system implementation.
[00143] Furthermore, given the integrated infrastructure of system 400,
additional
elements may be collocated or integrated with the above-described components
to further
enhance or extend processing resources and functionality. For example, a
central storage
device 442 may be included to provide additional secure/internal storage
usable in the
various processes invoked and implemented by the system 400.
[00144] Internal or external system sensors 426 may also be deployed, much as
described above with reference to integrated sensor monitors 326 of Figure 3,
so to
effectively monitor for, and detect, any one or more of external/internal
shell tampering;
unusual/unexpected system displacements, movements, or vibrations;
environmental
disbursements such as water, fire, heat or smoke; uncharacteristically high
system usages
and/or unusual usage patterns; etc.
[00145] The system 400 may further include and benefit from a resident high
precision
timing device 444, for instance, in supporting processes where high precision
timing may
be critical.
34
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00146] Using the above-noted approach, systems that would otherwise require a
stack
of interconnected devices using a set of networking cables and software-
defined network
port allocations (and generally at best satisfying commercial software or
hybrid security
standards such as FIPS 140-2), can now be implemented within a single
integrated
hardware architecture, that is within a single tamper-resistant shell and
optionally, within
a single integrated circuit board architecture, reaching security medium
assurance
(Communication Security Establishment ¨ CSE Canada) security standards or CSfC
(Commercial Solutions for Classified ¨ U.S. National Security Agency)
standards, and
beyond.
[00147] With reference to Figure 5, a network security zoning architecture is
shown (i.e.
for an ITSG-38 Compliant Application ¨see Information Technology Security
Guidelines
http s ://www. cse-cst.gc. ca/en/publication/itsg-38) in which a network path
is progressively
routed through various security zones. For example, a user can establish a
communication
link within a public zone (PZ, i.e. Internet) with a relaying party, which
then seeks to
establish a link to a public access zone (PAZ) that is deployed behind an
external firewall
(FWExT) and serviced by a first network attached HSM and proxy server to
establish
Transport Layer Security (TLS) Secure Tunneling with the relaying party. A
connection is
then extended to a restricted zone (RZ) that is itself deployed behind a
middle firewall
(FWmm) and serviced by its own network attached HSM to link into an App Server
to
initiate a Security Assertion Markup Language (SAML) Request validation and
TLS Setup
with a downstream database server (DB) deployed within a highly restricted
zone (HRZ).
The DB server deployed within the HRZ is once again deployed behind its own
internal
firewall (FWINT) and serviced by its own network attached HSM to provide TLS
termination and SAML Signature. Generally, using conventional network security
zoning
equipment, each firewall, HSM, the proxy server, the App server and the
database server
will constitute a distinct device stacked within a hardware stack and
interconnected via a
set of network cables, at best reaching a FIPS 140-2 security standard rating
(i.e. as defined
by Federal Information Processing Standards from the National Institute of
Standards and
Technology (NIST) for commercial cryptographic modules.
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00148] As illustrated in Figure 6, in accordance with one embodiment, the
network
security zoning architecture described above with reference to Figure 5 can,
in some
embodiments, be readily deployed using the integrated system hardware assembly
generically described above with reference to figure 4. For instance, each
integrated
processing engine 440 may be configured to implement a different system
firewall or server
such that a low security network link 450 can be channeled into the integrated
device 400
via a first external firewall 452 before invoking the integrated HSM 401 via a
first hardware
port thereof to invoke a first level security process therewith. Once
successfully
authenticated by the HSM 401, transaction data can be exchanged with a first
processing
engine 454 (e.g. proxy server of Figure 5), which can feed back into the HSM
401 via
distinct hardware ports to traverse a second firewall 456 and ultimately
invoke a second
level security process in order to access a second processing engine 458 (e.g.
App Server
of Figure 5). The HSM 401 is again leveraged to invoke a third level security
process in
order to access a third process engine 460 (e.g. database server of Figure 5).
Conversely, a
trusted high security link 462 can provide a more direct access to a high
security zone via
distinct HSM hardware ports.
[00149] As demonstrated above, the integrated security processing system
(appliance)
400 of Figures 4 and 6, can effectively improve security protocol ratings for
a given system
architecture while drastically reducing a required hardware rack footprint and
associated
host maintenance and security requirements. Namely, by integrating a
significant portion
if not the entire security processing system within a same tamper-resistant
shell, optionally
with associated tamper-monitoring sensors and/or devices, and further
optionally within a
same circuit board architecture, significant improvements in whole system
security,
reliance and maintenance can be realized. For example, noted improvements,
features
and/or advantages may include, but are not limited to, enhanced application
security, out-
of-the-box managed security service provider support, multi-tenant ready,
higher than FIPS
assurance, true hardware-based process isolation, trusted boot applications,
secured field
updates, quantum resistant cryptography, physical and operation security, to
name a few.
[00150] Furthermore, while the above provides one exemplary implementation of
an
integrated security processing appliance, various integrated system
applications can be
36
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
designed to leverage the features, functions and advantages of the above-
described
embodiments. For instance, an integrated device may be configured to provide a
security
processing appliance that delivers functionality such as, but not limited to,
entropy as a
service functionality, smart data diode functionality, trusted data guard
functionality,
protocol adapters, redundant sanitizing functions, trusted comparators, filter
validation
functions, dual layer VPNs, or the like.
[00151] With references to Figures 10 to 25C, and in accordance with some
embodiments, systems and methods in which a multi-level network security
management
device can be utilized to securely control the passage of data/transactions
from one network
(security) zone, domain or level, to another while minimizing tampering
opportunities
and/or fraudulent use will now be described. For example, embodiments as
described
herein may be configured to securely relay data or transactions, in a common
hardware
infrastructure, from one network security zone to another, for instance, by
securely
channeling data access and/or traffic in hardware between distinct zone-
specific hardware
ports respectively interfacing with these zones. For example, in one
embodiment, the
network management hardware platform may comprise a trusted (intelligent)
switch or
connection matrix, generally implemented in hardware and having a set of
designated or
reconfigurable hardware ports/relays to interface with a corresponding set of
distinct port-
specific and/or zone-specific processing engines, processes and/or resources.
In some of
the embodiments described below, each or at least some of the network zones,
processes
and/or resources are integrally defined within a common hardware appliance or
platform,
though other embodiments may rather encompass all or some externally
addressable zones,
processes and/or resources while maintaining internal hardware port
specificity and
integrity. In operation, the port-specific interconnection of the various
internal and/or
external resources with the centralized trusted switch, can define, in
combination, a multi-
level network architecture having secured data traffic or access management
capabilities
between such zones.
[00152] For example, in one such embodiment, a multi-zone architecture may
comprise
three distinct network zones having incremental data security ratings (e.g.
unclassified,
confidential, secret, etc.). Each zone will interface with a trusted set of
zone-specific
37
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
resources, each interconnected in hardware to securely execute intra and inter-
zone security
and/or management processes via dedicated hardware interconnections that are
specific to
these zones, i.e. data traffic between zones is exclusively channeled through
these
hardware-integrated data communication paths. Likewise, security protocols to
be applied
between zones are integrally implemented by security resources integral or
integrally
coupled (e.g. hardwired) to these paths via designated circuitry, relays,
integrated and/or
inline processing resources, or the like.
[00153] To illustrate one exemplary implementation, an event that occurs in a
first
security zone (e.g. zone A) may trigger a data transaction with a higher
level, e.g. zone B.
1() To
execute this transaction, zone A must first interface with the trusted switch
via a first
designated hardware port thereof and zone-specific security resources applied
thereto. As
illustrated in some of the examples below, such zone-specific security
resources may
include one or more integrated processing engines and/or related hardware
resources
which, in some respects, may define its own network security zone (e.g. zone
X) having its
own zone-specific hardware ports (e.g. a network security enforcement and/or
auditing
zone or resources specifically defined in hardware to supervise transactions
between zones
A and B). Upon successful carriage of the zone-specific security protocol on
the transaction
data received via the zone A port, the data transaction may successfully carry
through to
zone B via distinct zone-specific hardware ports. Accordingly, zone X may act
as a secure
auditing or security enforcement resource between zones A and B, whereby data
transactions to be implemented between these zones are necessarily transacted
via zone X
and the corresponding zone-specific hardware ports associated therewith of the
secure
switch. In doing so, while either or both network zones A and B may be
external to the
traffic security management device, by exclusively channeling transactions
between these
zones through a centralized hardware switch and having hardware port-specific
security
management resources integrated therewith, network and traffic security
breaches can be
minimized.
[00154] Following from the above example, the intelligent switch and port-
specific
channel resources and/or zones may be extended to further network zone levels,
for
example, where a resulting transaction event in zone B invokes or forwards a
transaction
38
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
with a further zone C, for instance, which may involve distinct security
measures that can
be carried out by inline channel resources and/or a specifically addressable
network
security enforcement or auditing zone Y. As will be appreciated by the skilled
artisan, in
some embodiments, some of the inter-zone security auditing and/or enforcement
resources
may be distinctly defined to interface exclusively with their dedicated
zone(s), and/or be
shared between auditing/enforcement levels through corresponding hardware
links and/or
relays depending on the level of security required.
[00155] In some embodiments, inter-zone security enforcement resources may
channel
inbound data through a data diode (i.e. one-way data flow) hardwired to the
inbound level-
specific hardware port. One or more security measures can then be applied to
the inbound
data for validation, such as authentication, filtering, logging, tapping,
setting, etc., which
is only released to the next level via a distinct level-specific hardware port
upon
successfully satisfying the applied security measures.
[00156] In one embodiment, the inter-zone security enforcement resources may
outright
block the data transaction until security measures have been successfully
applied. For
example, an inbound transaction may be processed by the enforcement resources
and, if
successful (e.g. validated, authenticated, etc.), safely relayed (e.g.
encrypted) to the next
level to be processed thereby.
[00157] In other embodiments, the data transaction may rather proceed to the
next level
in an encrypted fashion, for example, whereby applied security measures are
used to
validate the transaction and then, and only then, release a decryption key or
like measure
to enable the next level to process the relayed transaction.
[00158] In the following examples, systems and methods are described, in
accordance
with different embodiments, in which a multi-level network architecture, or at
least a part
thereof, can be collapsed into a single integrated appliance thereby
significantly reducing
a physical footprint of a given architecture while also mitigating certain
security risks and
management challenges common to such network architectures, and that, without
invoking,
at least in part, common network virtualization solutions that inherently
introduce their
own security risks and disadvantages, as will be readily appreciated by the
skilled artisan.
39
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
As will be detailed further below, while some examples illustrated herein
contemplate the
provision of a wholly integrated multi-level solution, such as in the
provision of a fully
integrated solution that can internally invoke and execute processes
implemented in distinct
security zones, other solutions as contemplated herein may also, or
alternatively encompass
a set of interconnected appliances, for example, where each appliance may
nonetheless
take advantage of available internal processing engine multiplicity,
cryptographic
resources and/or associated hardware data path customizability, to implement
tiered or
scaled inter or intra-level processes in the ultimate deployment of a larger
scale network
infrastructure. Accordingly, appliances or systems as described herein to
enable the
deployment of an internal multi-level architecture, should be understood to
provide for the
deployment of multiple distinct hardware segregated processing resources,
interconnected
by a deployable hardware interconnection matrix, to deliver, alone or in
combination,
different layered, sequential, parallel and/or nested network security
services, resources
and processes. Accordingly, each appliance may, in and of itself, deploy
resources in
distinct hardware-segregated network security zones or domains, as can they be
combined
to securely transact, alone or in combination, within and between such network
security
zones and/or domains.
[00159] In
general, each integrated appliance will comprise a trusted intelligent switch
or interconnection matrix as its hub that can effectively channel network
resources and
transactions between various network components to provide a desired outcome,
all, in
some embodiments, within the confines of a secured integrated hardware design
and
enclosure. Namely, in some embodiments, the operational components of the
multi-level
networking appliance can be characterized by a single circuit board design, or
by an
interconnected board design, operatively mounted within a singular tamper
resistant shell,
for example, that provides a limited number of external physical input/output
interfaces,
i.e. to limit potential exposure to intra-network interface tampering,
reconfiguration and/or
hacking. Accordingly, network component interconnections and data channel
processing
is relegated to the trusted intelligent switch, which, in some embodiments,
can be deployed
as an embedded chip interfacing with the various appliance components via
defined chip
hardware ports. Additional channel resources, such as data security resources,
channel
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
routing, auditing, encryption, processing and/or validation resources, or the
like, may also
be included in some embodiments, as will be further detailed below.
[00160] With reference to Figure 10, and in accordance with one embodiment, an
integrated multi-level network appliance 1000 will now be described. The
appliance
generally comprises a trusted (intelligent) switch 1001, generally implemented
in hardware
and having a set of designated or reconfigurable hardware ports/relays 1002 to
interface
with a corresponding set of integrated processing engines 1040, which can be
configured
or dynamically reconfigured to implement various network system functions
that, in
combination, define a multi-level network architecture. Examples of integrated
engines
1() 1040
may include, but are not limited to, web servers, applications servers,
database
servers, firewalls, email servers, specialized traffic filters, application
compilers, network
access portals, protocol adapters, channel filtering and/or auditing engines,
appliance
administration engines, or the like, implemented alone or in various
combinations, to
produce a desired outcome. Each processing engine 1040 may rely on its own
isolated
processor (i.e. processing core(s)) and/or memory storage device(s), or again
rely on central
or shared processing resources. For instance, the appliance 1000 may further
comprise a
central storage media 1042 that may be accessed via the trusted switch 1001
and optionally
include one or more application or engine-specific storage resources,
partitions and/or
zones.
[00161] As noted above, integrated processing engines 1040 may also, or
alternatively,
encompass different intra or inter-zone auditing and/or security enforcement
engines, for
instance, invoked to ensure intra or inter-zone traffic and/or transactions
adhere to
internally defined and enforced security protocols. As will be described in
further detail
below, while such inter-zone auditing or management resources may encompass
distinct
integrated processing resources, such as that schematically illustrated by
integrated
processing engines 1040, these may also, or alternatively encompass or invoke
centralized
security processing resources, such as a multilevel hardware security module
(HSM) and
related resources, for example.
41
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00162] As described herein, the intelligent switch can define a trusted
communication
matrix 1014 that securely relays signals between the appliance's various
components and
network architecture levels in a trusted hardware implementation via its
corresponding set
of hardware ports/relays 1002 and embedded switch logic. In some embodiments,
the
switch 1001 thus effectively implements a trusted (intelligent) cross-bar or
like switch that
dictates multiport interconnections via distinctly defined communication
channels, thus in
some embodiments, defining a port interconnection or trusted communication
matrix.
[00163] In some embodiments, the matrix 1014 may further invoke certain
embedded
channel resources 1016 so to further enhance interconnection logic between
ports and port-
related processes, and thus allow for embedded security logic integration
within the
switch's integrated hardware architecture. These channel resources 1016 may be
integrated
and invoked in a one-to-one fashion, for instance, with integrated port
specificity in fully
maximizing secure process isolation, or again provided as a shared resource
that may be
invoked and implemented for different port-specific processes albeit without
exposing any
such processes to undue external tampering risks.
[00164] In the illustrated embodiments described in greater detail below,
different
channel resources may include, but are not limited to, data security resources
(e.g.
encryption/decryption, secured storage, or the like, later described within
the context of an
embedded hardware security module (HSM)), a data channel diode (i.e. to
restrict data
flows on a defined channel to a designated direction), a data channel filter
(i.e. to filter
channel data, for example, to limit throughput data to a particular subset of
retrieved data,
or again to systematically reconfigure or replace designated data elements on
a given
channel data path), a channel comparator (i.e. to invoke channel logic between
channels
based on a comparison of data being channeled thereon, for example, allowing
process
throughput only upon matching channel data), an inline encryption function
(i.e. to execute
inline IPSEC or TLS protocol, for example, and/or to implement an inline VPN
or like
communication tunnel), or a sniffer function (i.e. silent non-bypassable
logging), etc.
[00165] The variable and/or customizable nature of the interconnection matrix,
in some
embodiments, may also or alternatively allow for the deployment and execution
of different
42
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
trusted hardware network interconnection solutions, such as for example, in
linearly
channeling port-specific data transactions between hardware ports in one or
more one-to-
one hardware port interconnection configurations (e.g. to provide
(cryptographically)
secure/trusted hardware-segregated port-specific processing
paths), in
consolidation/merging/ multiplexing distinct data channels inbound via
distinct hardware
ports in a many-to-one configuration (e.g. to provide (cryptographically)
secure/trusted
data/transaction convergence processing paths), and/or in distributing and/or
demultiplexing a single network source across multiple port-specific
resources, services
and/or data communication paths in parallel in a one-to-many configuration
(e.g. to provide
(cryptographically) secure/trusted data/transaction distribution/dissemination
across
multiple data channels from a trusted/reliable source).
[00166] It will be appreciated that some or all, or again different channel
resources may
be integrated to provide different interconnection logic and functions between
port-specific
processes and thus enhance available internal process complexity and
flexibility in
providing a whole integrated solution, in some embodiments, embedded within a
singular
intelligent switch chip implementation.
[00167] Internal or external system sensors 1026 may also be deployed, much as
will be
described in further detail with reference to integrated sensor monitors 1226
of Figure 12A,
so to effectively monitor for, and detect, any one or more of
external/internal shell
tampering; unusual/unexpected system displacements, movements, or vibrations;
environmental disturbances such as water, fire, heat or smoke;
uncharacteristically high
system usages and/or unusual usage patterns; etc. Data acquired via external
system sensors
1026 may also partake in selected internal processes, for example in
furnishing a random
seed value for internal cryptographic or random number generation processes,
for example.
The system 1000 may further include and benefit from a resident high precision
timing
device 1044, for instance, in supporting processes where high precision timing
may be
valuable or critical.
[00168] Using the above-noted approach, systems that would otherwise require a
stack
of interconnected devices using a set of networking cables and software-
defined network
43
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
port allocations (and generally at best satisfying commercial software or
hybrid security
standards such as FIPS 140-2), can now be implemented within a single
integrated
hardware architecture, that is within a single tamper-resistant or tamper-
proof shell and
optionally, within a single integrated circuit board architecture, reaching if
not exceeding
in some embodiments described for example further below with reference to
Figures 13 to
21, NSA' s (U.S. National Security Agency) Commercial Solution for Classified
(CSfC)
and CSE' s (Canadian Communication Security Establishment) Medium Assurance
security standards.
[00169] As noted above, in some embodiments, the integrated (intelligent)
switch 1001
1() embeds
a multi-zone or level hardware security module (HSM), i.e. a hardware and in
some
cases a single-chip HSM and intelligent switch implementation, operable to
concurrently
service one or more of the appliance's applications and/or functions, which
would
otherwise require access to an external HSM, thereby reducing overall system
security and
increasing tampering risks. Again, the multi-level HSM may equally apply to
the provision
of cryptographic services to hardware segregated resources in a same or
distinct network
security zone depending on the integral or distributive nature of the
contemplated system
at hand.
[00170] In some embodiments, the HSM invokes one or more of the switch's
hardware
ports, which can be configured or reconfigurable to receive input
cryptographic data (e.g.
public data, public key, etc.) thereon to execute a designated cryptographic
process within
the HSM in servicing a particular computational process, application or
function, i.e. a
particular engine 1040 or transit between engines 1040. In general, received
input data will
be port-specific in that only input cryptographic data specific to the port on
which it is
received can be successfully processed. To do so, each hardware port will
generally have
defined in association therewith a corresponding hardware link or channel
(e.g. static
and/or reconfigurable hardware link, channel and/or switch) to a segregated
hardware
storage space or medium that stores secured port-specific cryptographic data
thereon
exclusively retrievable for processing as a function of received input data
specific to that
hardware port. For example, distinct embedded storage spaces or resources may
be
provided with respective hardware data links to their corresponding port, as
can distinct
44
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
storage partitions and/or zones be defined within a same embedded memory
storage
resource and accessed via dedicated hardware logic or the like. Namely,
distinct embedded
storage spaces or resources may encompass a physically segregated, separated
and/or
defined hardware storage space on one or more hardware storage devices (i.e.
memory
board, chip, component, etc.) that is physically paired, allocated and/or
associated with a
given port-specific cryptographic and/or application process. For example,
each storage
space may be designated or adapted to store one or more cryptographic keys
and/or like
cryptographic data usable in invoking and/or executing a given port-specific
process, as
can other application/process-specific data be securely stored to implement
functions for a
1()
particular level of the multi-level appliance. Accordingly, in some
embodiments, a
dedicated memory space may define a secure key space for a given cryptographic
process
and/or encompass storage capacity for other types of cryptographic and/or
other related
data. An integrated cryptographic or related engine, executed by an embedded
or hardware-
linked processor, can then be invoked to internally process the retrieved
secured
cryptographic data, for instance in conjunction with the input data, to
produce an intended
computation result.
[00171] Accordingly, the entire process can be relegated to the hardware space
without
invoking a software or application layer and thus, without opening the HSM to
tampering
opportunities that may otherwise present themselves in conventional HSMs, such
as
traditional network-attached HSMs. Conversely, the HSM embodiments described
herein
allow for a full, and in some embodiments a single-chip (i.e. static or
reconfigurable (e.g.
FPGA)) hardware solution that can be used to concurrently service multiple
applications
and/or processes from within a same tamper-resistant environment by virtue of
the
intelligent switch integration. Accordingly, the solutions provided herein may
allow for a
significant increase in security protocol ratings while also significantly
reducing, in some
embodiments, a hardware footprint required to implement complex network
security
architectures that, in most cases, would require the co-location of multiple
distinctly
executed HSMs internetworked with various external devices in a complex cabled
architecture.
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00172] Furthermore, in some embodiments, the HSM may allow for software,
firmware
and/or FPGA updates through a secured validation process. This validation
process may,
in some embodiments, only accept validated inputs by means of one or more
corresponding
hardware port through a "chain of trust" process via digital signatures using
quantum safe
.. algorithms, such as hash-based signature algorithms.
[00173] In accordance with different illustrative embodiments, different non-
limiting
examples of single-chip hardware solutions may be considered. In some
embodiments, a
Xilinx' s System on Chip (SoC) or Multi-Processor SoC (1\,/iPSoC) product may
be used,
such as Zynq and Zynq UltraScale+TM respectively. The Zynq product line is
known
to contain 2 ARM processors, memory components and Field Programmable Gate
Array
(FPGA) while the Zynq UltraScale+TM has 6 ARM processors, memory components
and FPGA. In a first exemplary embodiment, the Zynq device may be used
wherein one
of the two ARM processors implements an integrated processing engine 140, a
second
ARM processor handles all memory accesses and the FPGA implements the trusted
.. communication matrix 114 between external communication ports and internal
memory
and processing engine capability. In a second exemplary embodiment, the Zynq
UltraScale+TM is used wherein 5 of the 6 ARM processors are used as
independent
processing engines while the sixth processor is used for handling all memory
accesses and
the FPGA implements the trusted communication matrix 114 between the external
communication ports, internal memory and integrated engine capability. In a
third
exemplary embodiment, the Zynq UltraScale+TM is used where all of the 6 ARM
processors are utilized as independent integrated processing engines managing
their own
memory space and the FPGA implements the trusted communication matrix 1014
between
the external communication ports, internal memory and cryptographic engine
capability.
.. Other known and future technologies, hardware configurations and products
may also be
considered, as will be readily apparent to the skilled artisan, without
departing from the
general scope and nature of the present disclosure. Further illustrative
details, examples,
advantages and features will be described below with reference to exemplary
embodiments.
[00174] With reference to Figure 11, and in accordance with one exemplary
embodiment that follows from the above description, a hardware security module
(HSM)
46
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
supported intelligent switch, generally referred to using the numeral 1101,
will now be
described. In the illustrated embodiment, the HSM-supported switch 1101
generally
comprises a plurality of hardware ports 1102, at least some of which being
operatively
linked through hardware, e.g. direct hardware link or switch channel logic
1108, to a
corresponding port-specific hardware storage resource and key space 1104 (e.g.
distinct
embedded memory storage device, hardware memory storage partition and/or
zone). Each
port-specific hardware storage resource and key space 1104 can be configured
to store
secured port-specific cryptographic data (e.g. private encryption/decryption
key 1112) that
is only retrievable upon input of corresponding input cryptographic data from
a
corresponding port. In other words, secured data may be further secured by
virtue of
hardware port specificity, whereby input data received on an incorrect
hardware port will
fail to access corresponding secured data linked to this incorrect port, and
also fail to access
secured data linked with any other port. Upon successful input of external
data via an
appropriate hardware port 1102, corresponding secured data (e.g. key 1112) can
be
internally retrieved and processed by an integrated engine (i.e. cryptographic
engine 1110)
to deliver a desired outcome.
[00175] To further enhance anti-tampering measures, in some embodiments, the
HSM-
supported switch 1101 may be enclosed (e.g. along with other appliance
components)
within a tamper-resistant box, container or shell 1106.
[00176] As noted above, the provision of hardware-linked HSM ports and
segregated
storage resources enhances overall system integrity and resilience to external
tampering,
while also providing the added benefit of HSM multiplicity within a common
multi-level
network appliance and tamper-proof or resistant shell. In fact, certain
embodiments may
efficiently multiply HSM resource allocations within a single chip
implementation, e.g.
with embedded memory(ies), processor(s) and hardware logic, while leveraging
both the
added security of distinctly segregated hardware-linked storage resource
interfaces and the
option to share internal hardware resources, such as a common integrated
cryptographic
engine 1110 that may be invoked to concurrently or at least sequentially
process secured
data from multiple isolated port-specific hardware storage resources and key
spaces 1104.
As will be described in further detail below, this integrated hardware
implementation may
47
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
further benefit the deployment of integrated secure system architectures, such
as multi-
level security system architectures and the like, all within the confines of a
single hardware
casing or shell, if not integrated onto a singular circuit board in some
embodiments.
[00177] As noted above, the embedded HSM-supported switch 1101 combines the
benefits of an integrated HSM with that of the intelligent switch
configuration.
Accordingly, in some embodiments, at least some of the hardware ports 1102 can
be linked
through hardware to interface with distinct storage resources 1104 and/or
ports 1102,
processes/data associated therewith, and/or link distinct appliance processing
engines as
described above, thereby defining a trusted communication matrix 1114 that can
be
1()
leveraged in more complex system implementations to benefit from the secured
co-location
of distinct resources on a same hardware implementation (e.g. same hardware
chip) without
exposing the device to external or software-related tampering risks. In other
words, port-
specificity can be maintained to govern access to secured data in executing
selected
cryptographic processes, and further enhanced by leveraging predefined
hardware
interconnections (i.e. data channels) between port-specific resources and/or
data
allocations.
[00178] The trusted communication matrix 1114 can be implemented as a set of
static
hardware relays and/or logic, and/or dynamically implemented via
reconfigurable
hardware logic and/or relays. Accordingly, certain port-specific HSM processes
invoked
by input data received via a particular port interface may be configured to
depend from
upstream cryptographic and/or network system processes executed in respect of
cryptographic data received on another hardware port and used to retrieve
distinctly stored
and maintained private data. Naturally, certain cryptographic processes may
equally feed
downstream processes executed in respect of a distinct port-specific data
resource. Given
the hardware implementation of the matrix 1114, system security logic and
complex data
channeling can be hardwired into the HSM-supported switch 1101 and thus
minimize
external exposure to tampering. Given the above, it will be appreciated that
while some
ports 1102 may be associated with corresponding storage resources 1104 in a
one-to-one
fashion, other port interconnection scenarios may be invoked to logically
associate a same
port with distinct storage resources, as can distinct storage resources may be
logically
48
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
associated with a same hardware port. Likewise, additional hardware port
interfaces may
be defined to execute certain channel interconnection configurations without
necessarily
forming a direct link with any particular storage resource 1104, for example
linking through
to other appliance processing engines and/or resources.
[00179] Furthermore, in some embodiments, the HSM may allow for software,
firmware and/or FPGA updates through a secured validation process. This
validation
process may, in some embodiments, only accept validated inputs by means of one
or more
corresponding hardware port through a "chain of trust" process via digital
signatures using
quantum safe algorithms, such as hash-based signature algorithms.
[00180] In accordance with one exemplary embodiment and similar to the single-
chip
hardware embodiments discussed in Figure 1, the presently described
embodiments may
be implemented using a Xilinx' s SoC or 1\,/iPSoC such as the Zynq product
line wherein
one of the two ARM processors implement the cryptographic engine 1110, a
second ARM
processor handles all memory accesses and the FPGA implements the trusted
communication matrix 1114 between ports 1102 and internal memory and
cryptographic
engine 1110. Other known and future technologies, hardware configurations and
products
may also be considered, as will be readily apparent to the skilled artisan,
without departing
from the general scope and nature of the present disclosure.
[00181] With reference to Figure 12A, and in accordance with yet another
embodiment,
an HSM-supported switch 1201, much as described above with reference to Figure
11, will
now be described. In this embodiment, the HSM-supported switch 1201 again
generally
comprises a plurality of hardware ports 1202 each operatively linked through a
direct
hardware link or switch channel logic 1208 to a corresponding port-specific
hardware
storage resource and key space 1204, in which secured port-specific
cryptographic data
1212 can be stored and securely retrieved to execute one or more cryptographic
processes
via an integrated engine 1210.
[00182] As with the embodiment of Figure 11, at least some of the hardware
ports 1202
can be linked through a direct hardware link or switch channel logic 1208 to
interface with
distinct storage resources 1204 and/or ports 1202, processes/data associated
therewith,
49
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
and/or accessible appliance processing engines and/or resources, thereby again
defining a
trusted communication matrix 1214. The matrix 1214 can again be implemented as
a set
of static hardware relays and/or logic, and/or dynamically implemented via
reconfigurable
hardware logic and/or relays.
[00183] In this embodiment, however, the matrix 1214 may further invoke
certain
embedded channel resources 1216 so to further enhance interconnection logic
between
ports and port-related processes, and thus allow for embedded security logic
integration
within the HSM's integrated hardware architecture. These channel resources
1216 may be
integrated and invoked in a one-to-one fashion, for instance, with integrated
port specificity
in fully maximizing secure process isolation, or again provided as a shared
resource that
may be invoked and implemented for different port-specific processes albeit
without
exposing any such processes to undue external tampering risks.
[00184] In the illustrated embodiment, different channel resources are
schematically
illustrated to include any one or more of a data channel diode 1218 (i.e. to
restrict data
flows on a defined channel to a designated direction), data channel filter
1220 (i.e. to filter
channel data, for example, to limit throughput data to a particular subset of
retrieved data,
or again to systematically reconfigure or replace designated data elements on
a given
channel data path), a channel comparator 1222 (i.e. to invoke channel logic
between
channels based on a comparison of data being channeled thereon, for example,
allowing
process throughput only upon matching channel data), an inline encryption
function 1224
(e.g. to execute inline IPSEC or TLS protocol, for example, and/or to
implement an inline
VPN or like communication tunnel), or sniffer function (1225).
[00185] For example, in some embodiments, an inline encryption function may be
invoked to facilitate certain encrypted exchange with an end or internal
client, process or
application, that do not necessarily require access to the cryptographic
engine and related
higher security protocols. For instance, while critical private key management
processes
(e.g. control plane processes such as user/client
authentication/authorization, authenticated
session initiation and configuration, private key generation and management,
system
management functions, etc.) may be strictly relegated to the cryptographic
engine and
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
defined secure key spaces, less critical processes (e.g. communication plane
processes,
such as authenticated data access transactions, updates, edits, etc.,) for
instance executed
on the basis of a symmetric and/or ephemeral (e.g. session) key used to
expedite processing
and communications, may be implemented via the inline channel encryption
resource 1224.
In so doing, the HSM-supported switch 1201 may integrally combine enhanced
control
plane cryptographic services, as described above, with inline cryptographic
services, all
within a same hardware design and configuration. This may, for example,
readily allow for
a singular hardware design, as described herein, to replace an otherwise
common network
(e.g. banking) architecture in which control plane functions and processes are
traditionally
1()
relegated to a distinct network interfacing HSM, while session-based
cryptographic
functions are subsequently channeled through downstream network servers. The
integrated
configuration discussed herein may further, or alternatively, allow for the
integrated
execution of a virtual private network (VPN) or even nested VPNs to achieve a
layered
architecture within a single hardware design rather than to invoke a
distributed network
architecture in which security protocols are otherwise run on a higher network
(e.g.
TCP/IP) layer, and thus, more vulnerable to physical or external tampering.
[00186] As noted above, a sniffer or like function may also, or alternatively
be deployed
as an integrated and/or customizable channel resource, for instance, to
provide a silent non-
bypassable logging or network/channel tapping function to gain visibility on
network
channel communications. For instance, such channel resources may be non-
obstructively
used to monitor channel communications and raise a flag or alert upon
identifying
suspicious or anomalous channel activity, if not shutting down outright
communications
on this channel until remedial action can be taken.
[00187] In this particular embodiment, the HSM-supported switch 1201 is
further
provided with optional external sensor monitors 1226, for example, which may
take the
form of various sensors and/or monitors used to detect and report on system
breaches or
tampering. For example, sensors may include, but are not limited to,
integrated sound
sensors that may detect shell impacts or breaks; inclinometers or 3D
accelerometers to
detect displacement or physical reorientation of the shell; smoke, heat and/or
water sensors
to detect environmental issues and/or tampering (e.g. multiple temperature
sensors can be
51
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
used to detect tampering via differential internal temperature metering);
proximity or
motion sensors to detect presence of unauthorized personnel; location or
geofencing
sensors to detect unauthorized transport of the HSM-supported switch, and
overall
appliance in general, beyond a designed security zone; and other such sensors
as may be
appreciated by the skilled artisan. As noted above, data outputs from these
sensors may
also partake in certain trusted internal processes, for example, as random
seed values for
downstream cryptographic or random value generation processes.
[00188] The HSM-supported switch 1201 may further include an administrator
port
1228, such as a local (e.g. external appliance-based) USB port or dedicated
network port
interface to allow for secured administrative access to the switch 1201 and
allow for system
maintenance and reconfiguration as may be required or desired from time to
time. For
example, where the switch 1201 is implemented as a reconfigurable chip (e.g.
FPGA),
certain hardware resources and/or logic may be re-allocated or reconfigured to
address
system or security protocol changes or improvements. For example, the trusted
communication matrix 1214 may be adjusted to reflect new port allocations or
leverage
new or existing channel resources to further enhance security protocols,
introduce new
security levels or system integrations, or again refine existing protocols
with improved
processes and functions.
[00189] Again, in some embodiments, the HSM-supported switch 1201 may allow
for
software, firmware and/or FPGA updates through a secured validation process.
This
validation process may, in some embodiments, only accept validated inputs by
means of
one or more corresponding hardware port (i.e. administrator port 1228) through
a "chain
of trust" process via digital signatures using quantum safe algorithms, such
as hash-based
signature algorithms.
[00190] As illustratively described above with reference to Figures 11 and
12A, in some
embodiments, the HSM-supported switch (1101, 1201) may be configured to share
a
common cryptographic engine (1110, 1210), that is an embedded resource
executing one
or more cryptographic processes predefined in firmware and secured within the
confines
of the HSM's hardware architecture. Accordingly, respective secured
cryptographic data
52
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
(e.g. private key data or key space) can be respectively accessed and used by
the common
cryptographic engine from respective port-specific storage spaces (1104, 1204)
to render
secure HSM functions to respective port-specific masters (e.g. users, clients,
processes,
applications, etc.)
[00191] In such embodiments, similarly to some embodiments discussed with
respect to
Figures 10 and 11, a single-chip implementation may use a Zynq device
described above
wherein one of the two ARM processors implements the common cryptographic
engine
1210, a second ARM processor handles all memory accesses and the FPGA
implements
the trusted communication matrix 1214 between external communication ports
1202 and
1() internal memory and cryptographic engine 1210.
[00192] With reference to Figure 12B, an alternative HSM-supported switch
configuration 1201' is rather designed to define a respective cryptographic
engine 1210'
for each of the secured port-specific hardware storage resource and keys paces
1204'. By
replicating cryptographic resources, further hardware isolation (e.g. distinct
firmware
resources and/or firmware executed on distinct embedded processor cores) can
be achieved
in thus further enhancing the HSM function's tamper resistance.
[00193] In this exemplary embodiment, a possible single-chip hardware
implementation
may consist of using the Zynq UltraScale+TM chip wherein 5 of the 6 ARM
processors
are used as independent cryptographic engines 1210' while the sixth processor
is used for
handling all memory accesses and the FPGA implements the trusted communication
matrix
1214 between the communication ports 1202, internal memory and cryptographic
engines
1210'.
[00194] In yet another embodiment illustrated in Figure 12C, an alternative
HSM-
supported switch configuration 1201" again replicates cryptographic resources
1210" for
each of the defined port specific hardware storage resources and key spaces
1204", but in
this case, embeds these resources within the hardware design so to be invoked
before access
is granted to the respective port-specific key spaces. This may be
particularly useful in a
context where, for example, storage resources used to define the respective
key spaces are
provided external to an otherwise embedded HSM chip. In other words, HSM
resources
53
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
may leverage an external storage resource such as a co-located or integrated
flash drive or
hard drive to store private key or other secured cryptographic data for
exclusive access via
embedded port-specific cryptographic engines. The person of ordinary skill in
the art will
appreciate that other configurations may also be considered without departing
from the
general scope and nature of the present disclosure. A possible exemplary
implementation
may consist of using, as discussed above, a Zynq UltraScale+TM chip but
wherein all of
the 6 ARM processors are used as independent cryptographic engines 1210"
managing
their own port-specific hardware storage resource and key space 1204" and the
FPGA
implements the trusted communication matrix 1214 between the communication
ports
1202, internal memory and cryptographic engine 1210. Other known and future
technologies, hardware configurations and products may also be considered, as
will be
readily apparent to the skilled artisan, without departing from the general
scope and nature
of the present disclosure.
[00195] As noted above, using different aspects of the above-described
embodiments,
complex system architectures may be deployed on a single chip, or again on a
same
integrated board design, i.e. where an embedded multi-port HSM-supported
switch can be
integrated with other system hardware on a same or interconnected circuit
boards to deliver
a complex (e.g. multi-purpose, multi-level, multi-tiered, multi-user, multi-
zone, etc.)
network service and system as a whole, all in some embodiments, within a same
tamper-
resistant shell.
[00196] With reference to Figure 13, and in accordance with one embodiment, an
integrated security processing system 1300 will now be described, in which a
hardware-
implemented HSM-supported switch 1301, much as described above with reference
to
Figures 12A to 12C, is illustratively integrated to act as a multi-function
HSM within the
integrated system architecture of system 1300. In this particular embodiment,
the HSM-
supported switch 1301 illustratively comprises a plurality of hardware ports
1302 each
operatively linked through hardware to a corresponding port-specific hardware
storage
resource and key space 1304, in which secured port-specific cryptographic data
1312 can
be stored and securely retrieved to execute one or more cryptographic
processes via an
integrated engine 1310. Again, hardware ports 1302 can be linked through
hardware to
54
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
interface with distinct storage resources 1304 and/or ports 1302, and/or
processes/data
associated therewith, to define a trusted communication matrix 1314. The
trusted
communication matrix 1314 can again be implemented as a set of static hardware
relays
and logic, and/or dynamically implemented via reconfigurable hardware logic or
relays.
Embedded channel resources 1316 are also optionally provided to further
enhance
interconnection logic between ports and port-related processes.
[00197] Integrated with the HSM-supported switch 1301 are provided distinct
processing resources 1320 that may be configured to execute various system
processes that
rely, at least in part, on the cryptographic outputs of the HSM-supported
switch 1301,
and/or contribute inputs to the HSM-supported switch 1301 to be processed in
respect of
one or more downstream processes. Generally, these processing resources 1320
will
include one or more processing engines and storage media encoding various
machine
executable tasks and instructions to be processed thereby, for example, via
one or more
accessible processors or the like. Accordingly, a secure data path may be
internally routed
from one processing engine 1340 to the other via the integrated HSM-supported
switch
1301, in some embodiments, either internally hardwired via internal cabling or
direct
circuit board interconnections, so to effectively execute multi-level or multi-
function data
security system integration within a wholly integrated system implementation.
[00198] Furthermore, given the integrated infrastructure of system 1300,
additional
elements may be collocated or integrated with the above-described components
to further
enhance or extend processing resources and functionality. For example, a
central storage
device 1342 may be included to provide additional secure/internal storage
usable in the
various processes invoked and implemented by the system 1300.
[00199] Internal or external system sensors 1326 may also be deployed, much as
described above with reference to integrated sensor monitors 326 of Figure 12A
so to
effectively monitor for, and detect, any one or more of external/internal
shell tampering;
unusual/unexpected system displacements, movements, or vibrations;
environmental
disbursements such as water, fire, heat or smoke; uncharacteristically high
system usages
and/or unusual usage patterns; etc.
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00200] The system 1300 may further include and benefit from a resident high
precision
timing device 1344, for instance, in supporting processes where high precision
timing may
be useful if not critical.
[00201] Using the above-noted approach, systems that would otherwise require a
stack
of interconnected devices using a set of networking cables and software-
defined network
port allocations (and generally at best satisfying commercial software or
hybrid security
standards such as FIPS 140-2), can now be implemented within a single
integrated
hardware architecture, that is within a single tamper-resistant shell and
optionally, within
a single integrated circuit board architecture, reaching security medium
assurance
(Communication Security Establishment ¨ CSE Canada) security standards or CSfC
(Commercial Solutions for Classified ¨ U.S. National Security Agency)
standards, and
beyond.
[00202] Similarly to the previously described exemplary embodiments, the HSM-
supported switch 1301 may also allow for software, firmware and/or FPGA
updates
through a secured validation process wherein, in some embodiments, validated
inputs may
be accepted by means of hardware ports 1302 (or other ports) only through a
"chain of
trust" process via digital signatures using quantum safe algorithms, such as
hash-based
signature algorithms.
[00203] With reference to Figure 14, a network security zoning architecture is
shown
(i.e. for an ITSG-38 Compliant Application ¨see Information Technology
Security
Guidelines https://www.cse-cst.gc.ca/en/publication/itsg-38) in which a
network path is
progressively routed through various security zones. For example, a user can
establish a
communication link within a public zone (PZ, i.e. Internet) with a relying
party, which then
seeks to establish a link to a public access zone (PAZ) that is deployed
behind an external
firewall (FWEXT) and serviced by a first network attached HSM and proxy server
to
establish Transport Layer Security (TLS) Secure Tunneling with the relying
party. A
connection is then extended to a restricted zone (RZ) that is itself deployed
behind a middle
firewall (FWMID) and serviced by its own network attached HSM to link into an
App
Server to initiate a Security Assertion Markup Language (SAML) Request
validation and
56
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
TLS Setup with a downstream database server (DB) deployed within a highly-
restricted
zone (HRZ). The DB server deployed within the HRZ is once again deployed
behind its
own internal firewall (FWINT) and serviced by its own network attached HSM to
provide
TLS termination and SAML Signature. Generally, using conventional network
security
zoning equipment, each firewall, HSM, the proxy server, the App server and the
database
server will constitute a distinct device stacked within a hardware stack and
interconnected
via a set of network cables, at best reaching a FIPS 140-2 security standard
rating.
[00204] As illustrated in Figure 15, in accordance with one embodiment, the
network
security zoning architecture described above with reference to Figure 14 can,
in some
embodiments, be readily deployed using the integrated system hardware assembly
generically described above with reference to figure 13. For instance, each
integrated
processing engine 1340 may be configured to implement a different system
firewall or
server such that a low security network link 1350 can be channeled into the
integrated
device 1300 via a first external firewall 1352 before invoking the integrated
HSM resources
of HSM-supported switch 1301 via a first hardware port thereof to invoke a
first level
security process therewith. Once successfully authenticated, transaction data
can be
exchanged with a first processing engine 1354 (e.g. proxy server of Figure
14), which can
feed back into the HSM-supported switch 1301 via distinct hardware ports to
traverse a
second firewall 1356 and ultimately invoke a second level security process in
order to
access a second processing engine 1358 (e.g. App Server of Figure 14). The HSM-
supported switch 1301 is again leveraged to invoke a third level security
process in order
to access a third process engine 1360 (e.g. database server of Figure 14).
Conversely, a
trusted high security link 1362 can provide a more direct access to a high
security zone via
distinct HSM-supported hardware ports.
[00205] As demonstrated above, the integrated security processing system
(appliance)
1300 of Figures 13 and 15 can effectively improve security protocol ratings
for a given
system architecture while drastically reducing a required hardware rack
footprint and
associated host maintenance and security requirements. Namely, by integrating
a
significant portion if not the entire security processing system within a same
tamper-
resistant shell, optionally with associated temper-monitoring sensors and/or
devices, and
57
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
further optionally within a same circuit board architecture, significant
improvements in
whole system security, reliance and maintenance can be realized. For example,
noted
improvements, features and/or advantages may include, but are not limited to,
enhanced
application security, out-of-the-box managed security service provider
support, multi-
tenant ready, higher than FIPS assurance, true hardware-based process
isolation, trusted
boot applications, secured field updates, quantum resistant cryptography,
physical and
operation security, to name a few.
[00206] Furthermore, given the integrated architecture of the security
processing system
described above, and in particular, the secured integrated network security
zoning
architecture, a multi-tier administrative access protocol may be deployed to
provide
selective remote or external administrative access to distinct zone resources
and/or the
HSM-supported switch and its embedded resources based on respective
administrative
access authorization profiles. Namely, the integrated nature of the herein-
described
embodiments may enable such distributed access authorization profiles to be
formed and
leveraged via a common administrative access interface and/or port, thereby
avoiding the
otherwise commonly required local administrative access to distinct network
resources or
again the provision of distinct administrative interfaces commonly available
for each
network resource and device in conventional physically isolated network
stacks. For
instance, one particular administrative access profile may provide
authenticated access to
certain network-user-related resources, whereas another may rather or
additionally provide
authenticated access to an application server and related resources, and
whereas yet another
may provide restricted access to administrative functions of the HSM-supported
switch,
for instance, to implement system security updates (cryptographic engine
update, HSM
access protocol improvements, etc.), reconfigure and/or update respective data
channel
paths and/or resources, etc. It will be appreciated that certain authenticated
administrative
access profiles may allocate access privileges to one or more zones and/or
system
resources, while restricting other zones and/or resources to other profiles.
[00207] While the above provides one exemplary implementation of an integrated
multi-level security processing appliance, various alternative integrated
system
applications can be designed to leverage the features, functions and
advantages of the
58
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
above-described embodiments. For example, this integrated appliance may also
be
envisioned as a part or to include a Universal Cybersecurity Platform (UCSP),
wherein said
platform integrates a variety of cybersecurity measures. Such a platform may
comprise a
single or multiple software tools/packages that allow to integrate multiple
cybersecurity
features such as key management, access to cryptographic algorithms, including
quantum-
safe cryptographic algorithms, zoning applications, patch management, secure
boot, etc.
[00208] With this in mind, the integrated device itself may be configured to
provide a
security processing appliance or platform that delivers functionality such as,
but not limited
to, entropy as a service functionality, smart data diode functionality,
trusted data guard
1()
functionality, protocol adapters, redundant sanitizing functions, trusted
comparators, filter
validation functions, dual layer VPNs, or the like. Examples of such
implementations will
be provided below, in a non-restrictive manner.
[00209] With reference to Figure 16, and in accordance with one embodiment, a
combined Entropy as a Service (EaaS) and Time Service system 1600 will now be
described, in which a full EaaS and Time service system is implemented within
a single
integrated security processing appliance (SPA), platform or like device. In
general, the
security of cryptographic applications depends strongly on the secrecy of the
cryptographic
keys. These must be very difficult to guess and the strength of a given key is
strongly
dependent on a measure of randomness called the Shannon entropy, or just
entropy in the
present context. Usually, sources of true randomness can be provided by low-
level,
statistically random noise signals, such as thermal noise and other stochastic
or quantum
phenomena. The higher the entropy available to a computing system, the more
random and
secure the generated keys will be. Standard computer systems, especially IoT
devices, have
difficulty producing good randomness. Using a EaaS system, these networked
systems and
devices can request high-entropy random data and fresh timestamps from the
EaaS & Time
Service server to increase the strength of locally generated encryption keys
on boot.
Currently such a service would be provided over the Internet, which provides
for security
issues. Conversely, the illustrative embodiment of Figure 16 provides the
advantage of a
fully integrated EaaS & Time service system implemented within a single SPA
while also
59
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
offering port-specific security features similar to those discussed in the
previous
embodiments.
[00210] As illustrated, system 1600 comprises an integrated EaaS and time
service
engine 1602, to which external port-specific connections are first made
through integrated
external firewall (FWEXT) engine 1638. The service engine 1602 is further
operatively
linked through hardware to a corresponding port-specific hardware storage
resource and
key space 1604 by means of a trusted communication matrix 1614, in which
secured port-
specific cryptographic data can be stored and retrieved to execute one or more
cryptographic processes via an integrated cryptographic engine 1610, for
example.
Accordingly, the integrated service engine 1602 can send back port-specific
timestamps
and entropy data to external systems and devices connected to the SPA 1600.
[00211] In
the illustrated embodiment, a high precision timestamps (e.g. fully
compatible with the NTP and PTP formats) are provided by an operatively linked
resident
high precision timing device 1644, such as an on-board atomic clock or
similar.
Meanwhile, entropy data is provided by an integrated port-specific EaaS server
engine
1606, deployed behind an integrated middle firewall (FWMID) engine 1640. The
EaaS
server engine is itself operatively linked to a secured (distinct) hardware
storage resource
1604 and integrated cryptographic engine 1610 by means of trusted
communication matrix
1614.
[00212] In this example, the integrated EaaS server engine 1606 is operatively
linked to
an entropy source 1620, comprising one or more noise sources 1666 which
provide the
non-deterministic, entropy-providing activities. The one or more noise sources
may
illustratively comprise, but are not limited to, a quantum random number
generator device
(QRNG), random thermal noise measured from ring oscillators or diodes or
similar, or like
sources known in the art. As each individual noise source may be contaminated
by a small
amount of bias, the entropy collected from each source can be combined and
processed by
a given cryptographic engine 1611 (i.e. applying conditioning functions such
as those
described in the NIST 5P800-90 family of documents) to create higher quality
entropy
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
data. The cryptographic engine 1611 securely feeds the entropy data back via a
data
channel diode to the integrated EaaS server engine 1606.
[00213] To assess the quality of the entropy produced by the noise source, the
data is
also continuously transmitted via another data diode 1618 to an integrated
health
monitoring processing engine 1626 that does health monitoring of the noise
source using a
series of statistical tests, such as the NIST SP 800-90B tests, for example.
In the case where
the entropy data fails one of these tests, the integrated processing engine
1626 can send a
failure signal back to the integrated EaaS server engine 1606 to alert the
system that the
entropy data is compromised.
1() [00214] In the illustrated embodiment, in order to implement the health-
monitoring
function, an intervening channel resource comparator 1622 is interposed
between health
monitoring engine and noise source outputs. For example, where the health
monitoring
engine outputs the same noise value it received as input, the comparator will
allow the
signal to go through to the EaaS server engine 1606, otherwise, the comparator
error output
will flag the EaaS server engine 1606 as to the inadequate EaaS value(s).
[00215] As
will be appreciated by the skilled artisan, the illustrated embodiment is
compatible with open source EaaS programs such as Pollen and Pollinate used to
transmit
and fetch entropy data. As in previously described embodiments, the integrated
system
described herein is controlled via a unified configuration and management
interface. This
interface can also be used to efficiently manage both the central deployment
of software
patches and security updates.
[00216] Figure 17 provides a schematic representation a Smart Data Diode (SDD)
1700,
in accordance with another exemplary embodiment. The SDD, as illustrated, can
efficiently
and securely isolate network traffic originating from outside a trusted
network (the egress)
from network traffic originating from inside the trusted network (the
ingress). In contrast
to the usual implementation of a data diode system, which provides a single
unidirectional
barrier between networks, the present embodiment integrates two physically
separated
unidirectional barriers within a single security processing appliance (SPA).
As designed,
61
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
the smart data diode can process both the Egress and Ingress traffic while
isolating each of
them behind separate data diodes.
[00217] As shown in Figure 17, a low side (untrusted network) connection first
goes
through a low side firewall (FWLO) 1704 to an integrated Low Side Protocol
Server
(LSPS) 1706 while a High Side (trusted network) connection goes through a High
Side
Firewall (FWHI) 1730 to an integrated High Side Protocol Server (HSPS) 1728.
Each
connection to and from the integrated Protocol Servers 1706 and 1728 are made
via a
trusted communication matrix 1714, as described above. The matrix can again be
implemented as a set of static hardware relays and/or logic, and/or
dynamically
implemented via reconfigurable hardware logic and/or relays. It will be
appreciated that
while the matrix 1714 is illustratively replicated throughout the SPA
schematic, a same
central or hub matrix 1714 may be commonly implemented to effectively
interconnect the
illustrated components in hardware, as described above.
[00218] In the illustrated embodiment, communication between the HSPS and the
LSPS
are physically separated between the Ingress and Egress. Each process transits
via an
integrated processor (Egress Processor 1726 and Ingress Processor 1724)
coupled on both
sides by a data diode. This ensures that the processing of the ingress traffic
is restricted to
Low Side to High Side communication (via diodes 1720 and 1722) while the
egress traffic
is restricted from the High Side to Low Side communication (via diodes 1716
and 1718).
These integrated components guarantee a physical separation in hardware of the
Egress
and Ingress traffic processing, all within the context of an integrated SPA.
This integration
can also enable the use of a unified configuration and management interface,
which can in
part be used to efficiently manage both the central deployment of software
patches and
security updates.
[00219] Figures 18 to 20 schematically illustrate an exemplary embodiment of a
Trusted
Data Guard system executable within the context of a single SPA, as defined
above. For
example, as shown in Figure 18, a Trusted Guard physically separates an Egress
traffic
flow from an Ingress traffic flow, and for each implements a series of inline
validation and
sanitizing functions. The following description applies both for the Ingress
traffic (going
62
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
from the Low side to the High side) and the Egress traffic (going from the
High side to the
Low side).
[00220] The data is first processed by a Protocol Adapter (PA) which extracts
information objects from the transmission protocols. These information objects
can consist
of a fixed format data object such as Military VMF (Variable Message Format),
US MTF
(US Military Text Format), JSON, XML, 0TH Gold (Over The Horizon) or similar.
The
PA also implements different communication protocols such as SFTP, HTTP/HTTPS,
Raw
UPD/TCP, serial protocols or similar. After extracting the necessary data, the
PA sends the
data to two independent implementations of a Sanitizing Function. These
functions
implement a sanitizing algorithm, which removes malicious data from the input.
The
implementation of each function is independent, which means that they can be
written in
different programming languages (such as SWIFT, .Net C#, Java or similar), use
different
component libraries (such as Daffodil, Xerces, SAXON, libXML, Xalan, libXSLT
or
similar) or even be executed on different operating systems (such as Linux,
SELinux,
OpenBSD, Windows or similar).
[00221] The two independent implementations must arrive at the exact same
result. To
do this, both Sanitizing Functions send their output to a Trusted Comparator
Function
(TCF), which compares the two streams of data. The streams may be of any
length and if
any portion of the streams fails to compare, the TCF completely discards the
data. If both
data streams are exactly the same, the TCF sends the data to a Filter
Validation Function
(FVF), which executes the final verification of the information objects format
and re-
format the objects into an appropriate native format. The treated data objects
are finally
sent to an outgoing Protocol Adapter, which again translates the information
objects into
the right transmission protocol before forwarding it.
.. [00222] Figure 19 shows in more detail the components of the Redundant
Sanitizing
Function (RSF) and the Filter Validation Function (FVF). In the case of the
RSF, the
information object is first processed by a DFDL (Data Format Description
Language)
parser to generate a XML formatted data object, which is read by a first
validator function
(Validator #1) to determine if the data is in proper form. The validated data
object is then
63
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
processed by a sanitizing function (Sanitizer) to remove malicious data and
processed again
by another validation function (Validator #2). Finally, the data object is
sent to the
Comparator Protocol Adapter (CPA) which finally transfers it to the TCF
function. In the
case of the Filter Validation Function (FVF), the data object is first
received from the TCF
function via a CPA, which forwards it to a validation function (Validator #2)
before
sending it to the DFDL Parser function.
[00223] Figure 20 shows one possible implementation of the system described in
Figures 18 and 19 within the context of a SPA. The integrated embodiment of
Figure 20
comprises an integrated (intelligent) switch (NGX) 2014, schematically shown
here to
encompass various channel resources as noted above, to interface between
various
integrated SPA components. As with previous embodiments, it will be
appreciated that a
same interconnecting hardware switch 2014 may be implemented within this
design to
implement the various functions illustrated herein, as can distinct hardware
switches be
cooperatively designed.
[00224] For both Ingress and Egress data flows, the NGX unit implements the
TCF in
hardware as a channel data comparator (comparators 2006 and 2012 for Egress
and Ingress
respectively). The channel data comparator implements logic between channels
based on a
comparison of data being channeled thereon, for example, allowing process
throughput
only upon matching channel data, thereby implementing the full functionality
of the
described TCF. For both the Egress and Ingress traffic, the incoming data
objects from RSF
#1 and RSF #2 are funneled through a data channel diode to ensure that the
data flow is
restricted to data going from the RSF to the TCF. This is shown in Figure 20
for the Egress
as the data objects coming from RSF #1 is sent via data diode 2004 while the
objects
coming from RSF #2 are funneled through data diode 2002, both connected to the
channel
data comparator 2006. Similarly, for the Ingress traffic, the data objects
from the RSFs is
sent via data diodes 2010 and 2008 to channel data comparator 2012. The NGX
unit also
implements, for both Egress and Ingress, through the use of data diodes the
functional
connection between the PA and one of the two RSF. Figure 20 shows that the
Egress traffic
passes through data diode 2016 when going form the PA to the Egress RSF #1 and
that the
64
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
Ingress traffic goes through data diode 2018 when moving from the PA to the
Ingress RSF
#1.
[00225] Figure 21 provides another exemplary implementation of an integrated
security
processing appliance as described herein, for the implementation of a Dual
Layer Virtual
Private Network (VPN) 2102. In this example, two connected VPNs and associated
firewalls are integrated into a single hardware SPA. Network traffic from a
local network
is first routed through an internal firewall (FWINT) 2120 to an integrated
processing
resource linked to a third party or open source VPN referred here as the Inner
VPN 2118.
This VPN is itself operatively linked to what is referred to as the Outer VPN,
which consists
of an inline channel encryption resource 2108. Each VPN (Outer and Inner) is
operatively
linked through hardware to a corresponding port-specific hardware storage
resource and
key space 2104 by means of trusted communication matrix 2114 in which secured
port-
specific cryptographic data can be stored and retrieved to execute one or more
cryptographic processes via an integrated cryptographic engine 2110. The Outer
VPN is
itself connected to the outside network via an external firewall (FWEXT) 2106.
Each
connection to and from each VPN is routed through a trusted communication
matrix 2114,
implemented as a set of static hardware relays and/or logic, and/or
dynamically
implemented via reconfigurable hardware logic and/or relays. A unified
configuration and
management interface can again also be used to efficiently manage both the
central
deployment of software patches and security updates, for example.
[00226] With reference to Figures 22, and in accordance with one embodiment,
an
example of a trusted auditing system executable within the context of a single
SPA, as
defined above, will now be described. In this exemplary embodiment, an
incoming
transaction event 2205 that must be audited is received by the HSM 2203 via a
hardware
port-specific channel and securely stored in an internal buffer 2209 or
encrypted and sent
off to be buffered elsewhere in the system. Logging process 2213 proceeds to
audit the
content of event 2205 and produces an external cryptographically authenticated
audit log
message 2217 via a secure logger function 2219. Upon completion of the audit
log entry
2217, event 2205 will either be released from an internal buffer or the
decryption key will
be released to the system buffer 2209 to be processed by other segments of the
system via
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
secure transfer control 2223. While this example is illustrated in isolation
in Figure 22, it
can readily be applied as an inline or addressable channel resource through
designated
configuration of an associated interconnection matrix and/or appliance
resources. For
instance, a channel auditing function may be invoked and implemented by one of
the SPA' s
processing engines, or again wholly or in part relayed to an external resource
via an
appropriate hardware link and/or data port. This may, in part, depend on the
complexity of
the auditing process (e.g. basic cryptographic data logging via onboard
cryptographic
resources vs. more elaborate data channel filtering, validation,
authentication and/or related
processes) and resources required therefor. Likewise, while a single
channeling auditing
process and/or resource may be implemented within a given appliance, multiple
distinct
hardware segregated auditing resources may also or alternatively be deployed
depending
on the application at hand.
[00227] With reference now to Figure 23 and in accordance with one embodiment,
a
high-level schematic representation of a Cross-Domain Solution (CDS)
enforcement point
based on one or more SPAs configured in a CDS mode of operation (hereafter
referred to
as SPA-CDS) will now be described. As shown in Figure 23, a multiplicity of
domains
2305 are each operationally connected to one of a corresponding multiplicity
of SPA-CDS
2309. It will be appreciated that while a one-to-one architecture is
illustrated herein to
address multiple network security domains (zones), multiple zones may
alternatively be
wholly integrated within a single SPA (e.g. where greater processing density,
resources,
multiplicity and/or volumes are made available within a particular SPA
embodiment), as
can security processes involved in the processing of a same domain (zone) be
split or
distributed across multiple SPAs.
[00228] In the illustrated embodiment, each SPA-CDS is further operationally
connected to one another via a secure interface to a cross-domain network,
illustratively
referred to herein as "Elevator network" 2313. Elevator network 2313 is an
interconnect
point that allows the SPA-CDS devices, each dedicated in this example to its
own specific
corresponding security domain, to transfer encrypted data that can only be
delivered to a
specific destination security domain. In other words, network 2313 may act as
an "elevator
shaft" where domain-specific data, which is correspondingly encrypted for
domain
66
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
specificity, enters on a specific floor (i.e. security domain) and can either
be elevated or
lowered to another specific destination floor and only successfully decrypted
(processed)
thereon based on said domain specific encryption.
[00229] In some embodiments, each SPA-CDS may also interface to a third
private
network only visible to those SPA-CDS that are members of a given security
domain. This
is illustrated in Figure 24, where SPA-CDS 2405 provides three separate
network
interfaces: the security domain 2409, the filtering function network 2411 and
the elevator
network 2413. Filtering function network 2411, in this example, is host to one
or more
servers performing a variety of filtering processes. Each one of the filter
processes available
for a given security domain is specifically defined to perform the necessary
information
filtering required for information being transferred between specific security
domains.
Note that a SPA-CDS only enforces the requirement that all data being
transferred from
one domain to another has to pass through a filtering step, by ensuring the
data must pass
through the filtering process. The skilled artisan will understand that the
actual specifics of
what the filtering process does may be outside of the scope of SPA-CDS, as can
other
embodiments encompass internal filtering applications and/or engines as the
case may be.
[00230] With reference to Figures 25A to 25C, different examples of a
Universal Cyber
Security Platform (UCSP) using the above-described SPA-CDS will now be
described. In
the exemplary embodiment of Figure 25A, each SPA-CDS 2505 appliance comprises
four
independent processing engines (PE - herein labelled as WPE, SPE, EPE and NPE)
interconnected using described multiport HSM 2509, as illustratively described
above. In
this example, upon a SPA-CDS 2505 being turned on, HSM 2509 boots itself from
code
that is kept secure via active-tamper security mechanisms and a secure boot
procedure.
Once securely running, HSM 2509 proceeds to securely boot each of the UCSP
processing
engines with specific application capabilities. The UCSP then transitions to
an operational
state that performs the functionality it has been programmed to enforce. The
UCSP
augments the HSM' s active tamper security capabilities with additional
platform-level
tamper detection mechanisms to ensure that the entire appliance is fully
tamper resistant.
67
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
[00231] In some embodiments, each of the PEs may be implemented using single
board
computers based on IntelTM server-class processors running a security-hardened
operating
system and related application code. The specific application performed by the
various PEs
may be defined by the overall use-case enforced by the UCSP.
[00232] In some embodiments, the HSM combines the trusted communication matrix
with a quantum-ready component that provides generic cryptographic functions,
which it
enhances via a quantum-ready security framework built using post-Quantum
cryptographic
algorithms for things such as secure firmware and configuration updates.
[00233] In some embodiments, the HSM' s trusted communication matrix strictly
enforces communication flows and types between the PEs deployed in the UCSP.
The types
of communication flows may be bi-directional, uni-directional, filtered,
encrypted,
decrypted or similar. Furthermore, flows of communication between any two PE
may also
be completely blocked if the overall use case requires it.
[00234] With particular reference to Figure 25A, the SPA-CDS 2505 provides a
Cross
Domain Security solution based on a UCSP that implements a specific trusted
communication matrix configuration and set of processing engine (PE)
functions. As
illustrated in Figure 25A, information is first transferred from a source
element in security
domain 2511 to the SPA-CDS interface attached to that security domain. Within
the SPA-
CDS, the information is received using Protocol Adaptor (PA) function 2513,
which is
responsible to provide an appropriate protocol hand-off for the information.
Protocol
Adaptor 2513 runs on one of the multiple SPA-CDS processing engines (WPE in
Figure
25A). Once protocol adaptor 2513 has extracted a complete or partial unit of
information
deemed sufficient to be filtered and transferred to another domain, it pushes
the unit of
information onto Data Orchestrator (DO) 2515, which resides on a second
independent
processing engine of the SPA-CDS (SPE in Figure 25A). This transfer is
performed via
One-Way Channel (OWC) 2517 enforced by the trusted communication matrix using,
for
example, a data diode or similar. Once a unit of information is received by
Data
Orchestrator 2515, it is operable to determine the appropriate filter or set
of filter
function(s) that may need be applied to that specific type of information.
Data Orchestrator
68
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
2515 proceeds to orchestrate the appropriate filtering steps using one or more
filtering
systems deployed on network of filtering functions 2519. Data Orchestrator
2515 may
implement said one or more filtering function based on a wide range of
criteria. For
example and without limitation, a filtering function may be applied based on
the content
of the data being transferred; based on the meta-data of the data being
transferred (e.g.
headers or tags with information about the data); based on a time window (e.g.
from an
initial time and data to an end time and date); based on metering of data
transactions (e.g.
apply filter only for the first 1000 units of information received, for
example). Accordingly,
Data Orchestrator 2515, in some embodiments, may take the form of a cross-
domain data
validation engine, for example, operable to validate and thus approve (refuse)
or seek
approval for the data transaction to proceed to the next domain.
[00235] Upon having completed the necessary application of filters to the
specific unit
of information, Data Orchestrator 2515 then obtains the approval (or refusal)
for
furtherance of the given unit of information onto another destination security
domain. This
transition requires that Data Orchestrator 2515 transfers the specific unit of
information to
cross-portal (Elevator) Access Portal (EAP) 2523. EAP 2523 resides on a third
independent
processing engine (EPE) and is operationally connected to Elevator Network
2524. As
before, the transfer between Data Orchestrator 2515 and EAP 2523 is performed
via the
trusted communication matrix. However, in this case, the trusted communication
matrix
enforces an encryption (ENC) transform 2525 that encrypts the specific unit of
information
for a given destination security domain using a specific cryptographic key
assigned for that
security domain. The encrypted data then gets delivered to EAP 2523 of the
egress security
domain which transfers it to the ingress EAP 2523 of the destination security
domain. Upon
receiving an encrypted unit of information from a source security domain, the
ingress EPA
2523 pushes the encrypted unit of information to its local PA 2513. The
transfer between
EAP 2523 and PA 2513 is enforced by the ingress SPA-CDS HSM' s trusted
communication matrix. In this case however, the trusted communication matrix
enforces a
decryption (DEC) transform 2527 on the data. Upon receiving a decrypted unit
of
information from its local EAP 2523, the ingress SPA-CDS' s PA 2513 for the
destination
security domain re-assembles the various units of information into a complete
information
69
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
package and transfers it off to a destination customer using the appropriate
communication
protocol.
[00236] The SPA-CDS may also provide an Enterprise Administrative (EA)
function
2531 dedicated to the overall maintenance of the functions offered by each of
the deployed
SPA-CDS devices and residing on a fourth independent processing engine (NPE).
One of
these functions is the distribution of appropriate keying material of each ENC
2525 and
DEC 2527 transforms specific to the corresponding security domain(s) of the
destination/source SPA-CDS devices, as illustrated in Figure 25B. For example,
if a SPA-
CDS deployed as the CDS access point for security domain 1 is to only be
allowed to
1() transfer information to security domain 2 and security domain 3, then the
ENC 2525
function of that SPA-CDS would be pre-loaded with two specific transfer keys
{K1-2, Kl-
3}. Similarly, if that same SPA-CDS is allowed to receive data from security
domains {2,
3, 4}, then the DEC 2527 function would be pre-loaded with three specific
transfer keys
{K2-1, K3-1, K4-1}.
[00237] The EA 2531 capability also provides an overarching maintenance
function for
all of the sub-components of the offered solution. In this way, when PA 2513,
DO 2515,
EAP 2523, or even EA 2531 require software updates, these functions are
orchestrated by
EA 2531, as illustrated in Figure 25C. During a maintenance update, all of the
various
network accesses are disabled to allow the enterprise maintenance capability.
This
capability can be further extended to provide the maintenance and enterprise
level
management of the filtering functions dedicated to each deployed security
domains. The
types of communication protocols that can be handled by the SPA-CDS is
dependent on
the type of specific protocol adapters that are deployed on a given device. In
general and
without limitation, these can be both stream or packetized protocols.
[00238] The skilled artisan will understand that, in some embodiments, a
different
number of independent processing engines may be used from the four described
above.
[00239] While the present disclosure describes various embodiments for
illustrative
purposes, such description is not intended to be limited to such embodiments.
On the
contrary, the applicant's teachings described and illustrated herein encompass
various
CA 03119867 2021-05-13
WO 2020/107098
PCT/CA2019/051638
alternatives, modifications, and equivalents, without departing from the
embodiments, the
general scope of which is defined in the appended claims. Except to the extent
necessary
or inherent in the processes themselves, no particular order to steps or
stages of methods
or processes described in this disclosure is intended or implied. In many
cases the order of
process steps may be varied without changing the purpose, effect, or import of
the methods
described.
[00240] Information as herein shown and described in detail is fully capable
of
attaining the above-described object of the present disclosure, the presently
preferred
embodiment of the present disclosure, and is, thus, representative of the
subject matter
which is broadly contemplated by the present disclosure. The scope of the
present
disclosure fully encompasses other embodiments which may become apparent to
those
skilled in the art, and is to be limited, accordingly, by nothing other than
the appended claims,
wherein any reference to an element being made in the singular is not intended
to mean
"one and only one" unless explicitly so stated, but rather "one or more." All
structural
and functional equivalents to the elements of the above-described preferred
embodiment
and additional embodiments as regarded by those of ordinary skill in the art
are hereby
expressly incorporated by reference and are intended to be encompassed by the
present
claims. Moreover, no requirement exists for a system or method to address each
and
every problem sought to be resolved by the present disclosure, for such to be
encompassed
by the present claims. Furthermore, no element, component, or method step in
the present
disclosure is intended to be dedicated to the public regardless of whether the
element,
component, or method step is explicitly recited in the claims. However, that
various
changes and modifications in form, material, work-piece, and fabrication
material detail may
be made, without departing from the spirit and scope of the present
disclosure, as set forth
in the appended claims, as may be apparent to those of ordinary skill in the
art, are also
encompassed by the disclosure.
71
