WO2018157247A1

WO2018157247A1 - System and method for securing communications with remote security devices

Info

Publication number: WO2018157247A1
Application number: PCT/CA2018/050234
Authority: WO
Inventors: Robert Douglas; Chris Alexander; Pritesh Yogesh PATEL; Ahsan NAQVI; Ryan John MUELLER; Patrick FALBA; Anthony SNELL
Original assignee: Bioconnect Inc.
Priority date: 2017-02-28
Filing date: 2018-02-28
Publication date: 2018-09-07

Abstract

Systems, method, and computer readable media provide improved computer security through supporting the establishment of custom certificates, which among other secured features, can include customized security profiles that are generated and enhanced to incorporate additional safety features, such as original physical positioning, device make / model, orientation, altitude from floor, etc., which can be dynamically analyzed by a certificate authority or other authorization mechanism for determining whether access can be granted. In some embodiments, a dynamic level of deviation is acceptable from the information stored in the custom fields of the custom certificate. The custom certificate, in some embodiments, is a downloadable payload. The custom certificate increases the length of the "kill chain" by way of incorporating characteristics (e.g., immutable characteristics) of the remote security devices into the security certificates that make the custom certificates more difficult to overcome and falsify.

Description

SYSTEM AND METHOD FOR SECURING COMMUNICATIONS WITH

REMOTE SECURITY DEVICES

CROSS REFERENCE

[0001] This application is a non-provisional of, and claims all benefit, including priority to, US Application No. 62/464,831 , entitled: "SYSTEM AND METHOD FOR SECURING COMMUNICATIONS WITH REMOTE SECURITY DEVICES", filed February 28, 2017, hereby incorporated by reference in its entirety.

FIELD

[0002] Embodiments of the present disclosure generally relate to the field of networked devices, and more specifically, embodiments relate to systems and methods for remotely securing such devices.

INTRODUCTION

[0003] With the constant evolution and development of information technology, security threats and challenges are increasing, which intensify the concerns about cyber security among enterprises. While network security is often focussed on cyber-attacks from external sources, securing access to an enterprise's physical infrastructure is often overlooked.

[0004] Onboarding or conducting renewals of remote security devices is a particular challenge, as it is difficult to ascertain or control a level of compliance of the remote security device before connecting it to a network attachment point of the network. Accordingly, handling these untrustworthy devices and automatically ensuring compliance with cybersecurity protocols is desirable.

SUMMARY

[0005] Maintaining effective cybersecurity practices is a technically challenging endeavour at the threshold between physical devices and a secured network. The threshold between safe and unsafe devices is an important threshold to maintain. [0006] Attackers have utilized different techniques to breach secured systems, including physically tampering with systems, applying brute force attacks, overcoming communication protocols (e.g., Heartbleed bug in OpenSSL), tapping communications networks (e.g., packet sniffing), taking advantage of software vulnerabilities (e.g., buffer overflows, incorrect pointers, poor input validation).

[0007] Applicants have extensive experience with enterprise-level cybersecurity. In developing Applicants' products and services, an automated system for improved securing of communications with remote security devices has been developed to segregate devices and to maintain cybersecurity leading practices. [0008] The automated system applies technological improvements through a process to update or onboard a new security device prior to provisioning access to a secured system or infrastructure. The automated system, in some embodiments, includes physical data center devices that are coupled to remote control access devices, such as card readers, biometric scanners, door / gate controls, cameras, microphones, smartphones (having a multitude of sensors), among others. The new security devices are initially untrusted and an improved security mechanism is put in place before access is given to the secured system of infrastructure.

[0009] The security infrastructure, over a duration of time, encounters a diversity of different devices, such as different security or access control devices controlling different aspects of a facility (e.g., fob-based access control for doors, biometric access points for cabinet locks at a data center, on-going verification and validation through a smartphone), and each of these control devices may have different requirements and capabilities.

[0010] An organization's "kill chain" are the number of steps required to be overcome by a potential intruder in attacking the secured network. The longer the "kill chain", the more difficult it is for the potential intruder to overcome as there are more layers of defences. However, longer "kill chains" also introduce complexity and inconvenience users, whereby a larger number of steps are required to request and/or otherwise provision access. [0011] The system provides improved computer security through supporting the establishment of custom certificates, which among other secured features, can include customized security profiles that are generated and enhanced to incorporate additional safety features, such as original physical positioning, device make / model, orientation, altitude from floor, etc., which can be dynamically analyzed by a certificate authority or other authorization mechanism for determining whether access can be granted. In some embodiments, a dynamic level of deviation is acceptable from the information stored in the custom fields of the custom certificate. The custom certificate, in some embodiments, is a downloadable payload. The custom certificate increases the length of the "kill chain" by way of incorporating characteristics (e.g., immutable characteristics) of the remote security devices into the security certificates that make the custom certificates more difficult to overcome and falsify.

[0012] The system is configured to utilize the custom certificates in combination with approaches for emergency certificate renewal, whereby certificates are refreshed in an agile and efficient manner to respond to infrastructure threats or changes. For example, there may be a requirement to transition to a different standard (e.g., a protocol is breached, and there is a need to upgrade to a new protocol immediately), or a timed / periodic renewal period approaches. In these situations, the system is controlled to adopt two different certificates simultaneously, and one or both of the two different certificates may be pushed to the security device.

[0013] An ability to support custom certificates increases the complexity and decreases the likelihood that an assailant can actually re-engineer and weaponize the certificate. Utilizing standard certificates would increase the likelihood of being able to re-engineer the certificate but would still be protected by the certificate and data deletion from the local memory of the device. The certificates pinned to the devices can also be removed, updated and replaced directly from the application server. By enabling certificate removal at the device as well as by the server, the application is able to more easily manage the renewal of certificates. The system is adapted to improve the ease of moving a device's connection point from one application server to another. This is done by removing the certificate from the device and enabling connection with the other application server. Once the device is pointed at the new application server, the regular operation of "trust on first use" and other security measures are in place to ensure the device connects securely. This makes upgrades, physical infrastructure changes and system growth much more easy to manage while preserving an improved level of security. [0014] Upon removal of a device from the network, the secure certificates and all data is erased from the local memory of the device, providing an additional layer of security to prevent from the implications of a device being physically removed and stolen from the customer. If the device were to contain the custom certificates implemented by the customer or the unique certificates used to communicate to the application server, then the assailant would have access to these secure certificates. These stolen certificates could then be re- architected and compromised in the customer network. If the assailant were to access the network and utilize the re-engineered certificate then they would be able to reach into the network and interact with anything from the certificate authority to the application server.

[0015] In an aspect, there is provided a system for securing communications with remote security devices, the system comprising: one or more servers for controlling device integration with the system, the one or more servers comprising at least one processor configured for: receiving initial connection communications from a security device over a default communication link, the initial connection communications including at least one device-identifying field and device configuration data; comparing the at least one device- identifying field with a device access list defining devices permitted to access the system in a non-validated state; upon verifying the security device is authorized for integration with the system based on the comparison, determining a current firmware version for the security device; the security device is out-of-date, sending the current firmware version to the security device; transmitting a request to a certificate authority to generate a unique network access certificate for the security device based on at least one of the device-identifying fields; transmitting the unique network access certificate to the security device over an encrypted connection; transmitting operational settings to the security device, the operational settings and the current firmware version providing device configuration requirements required by system parameters to integrate with the system in a validated state; upon validating the security device for integration with the system: transmitting instructions to restart the security device with the current firmware and the transmitted operational settings; removing the security device from the device access list; receiving a secure connection request from the security device including the unique network access certificate; and permitting the security device to integrate with the system in the validated state. [0016] In another aspect, the default communication link is coupled to a network or a subnetwork segregated from an secured network or secured subnetwork requiring the network access certificate for communication.

[0017] In another aspect, the default communication link enables communication to a computing device coupled to the certificate authority. [0018] In another aspect, the network access certificate permits access to a RADIUS server coupled to the secured network or the secured subnetwork.

[0019] In another aspect, the unique network access certificate is a custom network authentication certificate augmented with one or more device-specific data fields indicative of one or more characteristics associated with the security device. [0020] In another aspect, the one or more characteristics includes at least one of MAC addresses, kernel version, firmware version, available operational modes, traceroute, network connection types, device serial number, manufacturer identifier, available functionality, physical location, angular orientation, and technical specifications.

[0021] In another aspect, the custom network authentication certificate is processed to generate a compressed custom network authentication certificate for deployment to the security device, the compressed custom network authentication certificate storing a subset of the one or more device-specific data fields; and the certificate authority, responsive to a future authentication request from the security device, regenerates the custom network authentication certificate from the compressed custom network authentication certificate prior to authenticating the custom network authentication certificate for controlling access to the secured network or the secured subnetwork. [0022] In another aspect, the subset of the one or more device-specific data fields of the compressed custom network authentication certificate exclude one or more network connection-specific or location-specific fields that the certificate authority is able to determine based on analyzing characteristics of received communications from the security device. [0023] In another aspect, the subset of the one or more device-specific data fields of the compressed custom network authentication certificate includes one or more selected device- specific data fields based on one or more data storage constraints of the security device.

[0024] In another aspect, the compressed custom network authentication certificate is transmitted to the security device in a series of ordered packets spaced temporally to manage transmission load across the encrypted connection.

[0025] In another aspect, the custom network authentication certificate establishes a trusted connection based on characteristics of the security device during initial registration of the security device on the certificate authority.

[0026] In another aspect, the certificate authority is configured to tolerate deviation up to a threshold deviation from the one or more device-specific data fields when controlling access to the secured network or the secured subnetwork.

[0027] In another aspect, the certificate authority, responsive to a communication request from the security device where the deviation is greater than the threshold deviation, revokes the custom network authentication certificate and requires re-registration of the security device.

[0028] In another aspect, the threshold deviation is dynamically determined by the certificate authority based on at least on a security level enforcing a intrusion kill chain model wherein a minimum number of security validation steps are required in validating any access to the secured network or secured subnetwork. [0029] In another aspect, the unique network access certificate includes a first portion storing a leaf node certificate and a second portion storing an encryption key associated with the leaf node certificate; and wherein the at least one processor of the system is configured to reconstitute a full chain certificate from the leaf node certificate and the encryption key, the full chain certificate being provided to the security device.

[0030] In another aspect, the leaf node certificate, the encryption key, and the full chain certificate are stored in one or more memory locations on a secured server accessible by the certificate authority.

[0031] In another aspect, the one or more memory locations on the secured server are transformed into one or more metadata fields stored in one or more memory locations on an access control server.

[0032] In another aspect, the unique network access certificate further includes one or more additional intermediate certificates, each intermediate certificate controlling access through one or more corresponding intermediate certificate authorities, and the certificate authority and the one or more intermediate certificate authorities are configured in a hierarchical model where the certificate authority has control over all intermediate certificate authorities, and each intermediate certificate authority has control over any intermediate certificate authorities residing below on the hierarchical model.

[0033] In another aspect, the at least one processor is further configured for: flagging the security device as unsafe and insecure upon a determination that the firmware version of the security device is out of date; controlling the security device to encapsulate and transmit to the system a data payload including one or more data sets representative of the at least one device-identifying field and the device configuration data; and wherein the verifying of the security device for authorization for integration includes at least validating the data payload by comparison with a security device template residing on the one or more servers for controlling device integration with the system.

[0034] In another aspect, the custom network authentication certificate is utilized to generate a first certificate and a second certificate, the first certificate encrypting the custom certificate using a first encryption mechanism, and the second certificate encrypting the custom network authentication certificate using a second encryption mechanism, the first certificate and the second certificate both transmitted to the certificate authority for authentication such that at least one of the first certificate and second certificate are utilizing an encryption mechanism accepted by the certificate authority.

[0035] Corresponding methods, computer readable media having machine readable instructions stored thereon are provided in various embodiments. DESCRIPTION OF THE FIGURES

[0036] In the figures, embodiments are illustrated by way of example. It is to be expressly understood that the description and figures are only for the purpose of illustration and as an aid to understanding.

[0037] Embodiments will now be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0038] FIG. 1A is a block schematic of a physical security infrastructure architecture, according to some embodiments.

[0039] FIG. 1 B shows aspects of an example system to which aspects of the present disclosure may be applied. [0040] FIG. 1C is an example block schematic diagram, according to some embodiments.

[0041] FIG. 2 is a schematic diagram showing aspects of another example system and data flow.

[0042] FIG. 3 is a flowchart showing aspects of an example method, according to some embodiments. [0043] FIG. 4 is a schematic diagram of computing device, exemplary of an embodiment.

[0044] FIG. 5 is a process diagram of a process for establishing a certificate for a physical access security device, according to some embodiments.

[0045] FIG. 6 shows two example processes for establishing TLS certificates and 802.1x certificates, according to some embodiments. [0046] FIG. 7A is an example data structure diagram of an example custom certificate, according to some embodiments.

[0047] FIG. 7B is an example of a truncated data structure used for a truncated custom certificate, according to some embodiments. [0048] FIG. 7C is an example of a data structure used for a custom certificate that is adapted to allow the system to tolerate a level of deviation, according to some embodiments.

DETAILED DESCRIPTION

[0049] Maintaining effective cybersecurity practices is a technically challenging endeavour at the threshold between physical devices and a secured network. Malicious actors employ a variety of techniques to falsify, tamper, or overwhelm cybersecurity defences. If an unauthorized individual gains access to an enterprise's physical infrastructure, the individual can use his or her physical access to launch an attack on or otherwise access the enterprise's electronic system and/or personnel. Many available physical access control systems and loT (Internet of Things) devices commonly have weak security relative to the protections afforded to external interfaces of a network. This may leave an enterprise's infrastructure and/or personnel vulnerable to physical or local attacks.

[0050] The threshold between safe and unsafe devices is an important threshold to maintain. Applicants are aware of several serious cyber security attacks where entire networks have been brought down and incapacitated by one or more seemingly minor violations of leading practices and/or breaches. These attacks have increased in severity in recent years and given the increased importance of computer networks and the information stored within, the impact of attacks has increased significantly.

[0051] Attackers have utilized different techniques to breach secured systems, including physically tampering with systems, applying brute force attacks, overcoming communication protocols (e.g., Heartbleed bug in OpenSSL), tapping communications networks (e.g., packet sniffing), taking advantage of software vulnerabilities (e.g., buffer overflows, incorrect pointers, poor input validation). The attackers, upon being to access the secured system, may steal information, maliciously encrypt files (e.g., ransomware), plant malware, delete information, etc.

[0052] In order to maintain a practically effective defense, there is increased importance in ensuring that physical devices utilize up to date firmware, kernels, software versions, etc., and connection types and communication protocols are in line with leading encryption practices. Physical devices are at a heightened risk of attack as, in addition to software / networking based attacks, physical devices may be physically tampered with, altered, damaged, etc. Applicants have encountered situations where malicious actors have taken biometric scanner devices off of mountings, opened the housings, and stolen certificates directly from on-board memory of the devices.

[0053] During penetration testing, test protocols typically include complex, multi-factor attacks, including combinations of social engineering, physical device tampering, network communications snooping / injection, exploitation of known vulnerabilities, script injection, among others. The penetration tests are adapted to simulate attacks conducted by malicious users, and have led to the development of strict cybersecurity techniques and protocols. Attacks include driver issues (e.g., Stuxnet), fake certificates (e.g., Comodo), revoked certificates (Diginotar), bogus certificate / breached web servers (e.g., GlobalSign), DDoS attacks (Getronics), improper administrative credentials, among others.

[0054] A security penetration assessment was conducted to identify security challenges in respect to various physical access security products in an enterprise environment. During the security assessment, a number of vulnerabilities were identified in respect of vulnerabilities of actual physical devices that verified and/or otherwise controlled physical or virtual access to the enterprise environments (e.g., door readers, server rack locks). The security assessment included software tampering (impersonation of devices through profiles and profile data), physical tampering of the devices (e.g., connecting devices via exposed USB ports, network connection ports, taking entire devices off mounts and reconnecting them elsewhere), tampering of network connections, and adapting known attack vectors that have not been adequately addressed despite updates being available. [0055] A particularly impactful vulnerability results from devices being out of compliance with enterprise security protocols, and this is a major problem when onboarding a new or previously unknown device. The new or previously unknown device arrives with an unknown configuration, and may be out of compliance with strict security standards (e.g., may have hard coded keys, may have exposed USB ports, may run media off of SD cards, may be set on "debug mode" where hidden menus are exposed).

[0056] The firmware update process itself may be fraught with vulnerabilities, as an attacker can remotely upload custom firmware, steal information, and/or attack other devices on a network. Accordingly, it may be helpful as described below in quarantining the firmware update on a separate network until verification can be conducted to ensure that the firmware is indeed updated correctly and not a compromised version (e.g., someone used a hex editor to replace bytes on a firmware image to compromise it, with a falsified checksum).

[0057] In an enterprise environment, strict security standards lead to technical challenges in maintaining cybersecurity protocols. For example, formal processes may need to be adhered to handle new device onboarding, upgrades, etc., and one or more change requests may need to be submitted for processing. In alternative approaches, a highly manual process can be utilized but is inefficient and prone to human error, especially as security standards and protocols are dynamically changing in response to newly discovered cybersecurity threats and solutions. This is especially evident where an organization is very large, and there are issues with slow adoption of leading practices and roll-out of required security patches, updates, and modified encryption mechanisms.

[0058] Applicants have extensive experience with enterprise-level cybersecurity. In developing Applicants' products and services, an automated system for improved securing of communications with remote security devices has been developed to segregate and to maintain cybersecurity leading practices. The automated system applies technological improvements through an automated process to update or onboard a new security device prior to provisioning access to a secured system or infrastructure. The automated system, in some embodiments, includes physical data center devices that are coupled to remote control access devices, such as card readers, biometric scanners, door / gate controls, cameras, microphones, smartphones (having a multitude of sensors), among others. [0059] FIG. 1A, FIG. 1 B, FIG. 1 C and FIG. 2 show aspects of an example system to which aspects of the present disclosure may be applied. FIG. 1C shows the security device 130 in interoperation with system 100 in protecting the secured infrastructure.

[0060] The automated system interoperates with policy-based certificate management systems as an overall part of a secured infrastructure.

[0061] The secured infrastructure may include, for example, testing servers, production servers, pre-production servers, domain controllers, messaging buses, data storage elements, backup servers, etc. The secured infrastructure is designed to handle highly sensitive information, such as client information, credit card data, personal information, and thus requires a high level of security. Different areas of the secured infrastructure may require differing levels of security (e.g., a secure data server likely requires a higher level of security than a testing server).

[0062] The automated system is a controller that, in some embodiments, is configured for insertion and/or configuration into an existing data center architecture to improve computer security in relation to physical access control devices, each of which are provisioned security certificates used to authenticate and validate communications from the physical access control devices. The automated system, in some embodiments, supports the generation, regeneration, and renewal of the digital certificates in accordance with an specific, unconventional approach adapted to improve cybersecurity. FIG. 3 is a flowchart showing aspects of an example method, according to some embodiments.

[0063] Physical devices are especially prone to attack, as the devices are often arrive and are connected to the network as out of date devices, having old versions of software, firmware, etc. An additional source of introduced vulnerability is the actual storage of identity certificates. The physical devices are connected through network access points, which may also be compromised. Through the course of Applicants' operations in the cybersecurity sector, Applicants have observed creative and wide-ranging attacks on physical devices to ultimately gain access and/or control of the secured infrastructure. [0064] Specific steps are required to ensure that a specially configured certificate can be generated and provisioned prior to access being granted. As described in various embodiments, systems, methods, and computer readable media are adapted for improvements in securing communications with remote security devices, whereby remote devices having a diversity of configurations can be on-boarded onto a secured system while maintaining security and segregation. FIG. 5 is a process diagram of a process for establishing a certificate for a physical access security device, according to some embodiments. FIG. 6 shows two example processes for establishing TLS certificates and 802.1x certificates, according to some embodiments. [0065] An organization's "kill chain" are the number of steps required to be overcome by a potential intruder in attacking the secured network. The longer the "kill chain", the more difficult it is for the potential intruder to overcome as there are more layers of defences. However, longer "kill chains" also introduce complexity and inconvenience users, whereby a larger number of steps are required to request and/or otherwise provision access. [0066] The system provides improved computer security through supporting the establishment of custom certificates, which among other secured features, can include customized security profiles that are generated and enhanced to incorporate additional safety features, such as original physical positioning, device make / model, orientation, altitude from floor, etc., which can be dynamically analyzed by a certificate authority or other authorization mechanism for determining whether access can be granted. In some embodiments, a dynamic level of deviation is acceptable from the information stored in the custom fields of the custom certificate. The custom certificate, in some embodiments, is a downloadable payload. The custom certificate increases the length of the "kill chain" by way of incorporating characteristics (e.g., immutable characteristics) of the remote security devices into the security certificates that make the custom certificates more difficult to overcome and falsify.

[0067] FIG. 7A is an example data structure diagram of an example custom certificate, according to some embodiments. FIG. 7B is an example of a truncated data structure used for a truncated custom certificate, according to some embodiments. FIG. 7C is an example of a data structure used for a custom certificate that is adapted to allow the system to tolerate a level of deviation, according to some embodiments.

[0068] In some embodiments, the custom certificate may be modified and the particulars of the custom certificate and its processing may be modified by an intermediary controller device that identifies a security level and a corresponding kill chain level / length required for that security level, such that each security device at a different security level may have different lengths / different customizations of customized security certificates. In some embodiments, processing time for certificates is an important consideration, and managing "fit for purpose" lengths and sizes of certificates is a factor in ensuring that systems are not unnecessarily slow or cumbersome for use. For example, for a main entrance door, it may be unacceptable to require a processing time of thirty seconds. On the other hand, a processing time of thirty seconds may be manageable where a user is attempting to gain physical access to a highly secured site, such as a data center or a secured vault.

[0069] The downloadable payload, in an example embodiment, is compressed and potentially truncated or otherwise reduced in size before providing to the remote security device. The full custom certificate, in some embodiments, is regenerated by an intermediary access control device or certificate server, and may include additional information, such as network access point / connection characteristics, among others.

[0070] Where network access point / connection characteristics are included, an additional layer of security is provided as not only is the remote security device authenticated, but also the connection characteristics are considered in determining whether access should be granted (e.g., prevents a malicious user from taking a terminal from one location and using it at another served by a different network connection).

[0071] In this example, if the compressed or truncated digital certificate is falsified (e.g., if it resides on on-board memory and is extracted from the on-board memory for malicious use), there are additional "kill chain" steps in the network communications and network access mechanism that could be used to flag or otherwise reject the digital certificate. For example, a malicious attacker may remove the security device from the wall and use it at a different network access point (e.g., removing a security device from a low level security access point and using it at a high level access security point in an attempt to use lower credentials to access an area requiring higher credentials). While the security device may still store the certificate on-board, the certificate, when ultimately provided to the certificate authority after re-constitution into the full custom certificate, may still fail as the steps of re- constitution with the network access point characteristics may be a failure.

[0072] Handling some level of deviation is important as remote security devices operate in practical environments where there may be slight changes that are innocuous. For example, a component of the custom certificate may include an angular orientation of the remote security device relative to a reference point (e.g., 0 degrees to the floor). However, over the course of use and interaction with individuals providing fingerprints via a biometric reader, the angular orientation may deviate slightly (e.g., 1 degree to the floor). Accordingly, the tilted orientation may not be indicative of malicious actions. On the other hand, where there is a shift of 15 degrees, there may be cause for concern and the angular shift may be indicative of an attack. [0073] However, there are practical limitations and considerations which lead to difficulties in implementation. Security devices, access connection points, and access connections have practical limitations, and increased security measures may result in incompatibility, unacceptable slow-downs, and operational problems.

[0074] The security infrastructure, over a duration of time, encounters a diversity of different devices, such as different security or access control devices controlling different aspects of a facility (e.g., fob-based access control for doors, biometric access points for cabinet locks at a data center, on-going verification and validation through a smartphone), and each of these control devices may have different requirements and capabilities.

[0075] For example, there may be differences in available on-board memory (e.g., only has flash memory to store firmware and templates up to 64 MB), processing capabilities (e.g., for encryption / decryption / matching / verification), connection (e.g., only supports 802.1 1 b or has a 10BASE-T wired connection). [0076] Furthermore, devices may be encountered at different stages of updating. For example, a new security device that is purchased from a vendor arrives with a default kernel / firmware version based on when it left the factory. It may or may not be the latest kernel / firmware version, and the security infrastructure may need flexibility in handling different configurations of devices. In some instances, these vulnerabilities may be the result of security device characteristics. For example, outdated or otherwise unsecure communication protocols may enable eavesdropping or may be a weak link in a network's security. In some instances, security devices, such as panels for unlocking doors, are by definition required to be accessible in unsecure areas which provides physical access to potential attackers. In some instances, vulnerabilities can be on the physical device and/or related to the physical hardware of the device. FIG. 8 is a process diagram of a security certificate renewal process, according to some embodiments.

[0077] The security OEM market is also fairly fragmented with many vendors lacking resources for updating systems and/or security expertise. In such an environment, providing a system for securing communications with remote security devices can be a challenge.

[0078] Referring to FIG. 1A, a block schematic of a physical security infrastructure architecture is shown, according to some embodiments.

[0079] The physical security infrastructure is implemented using a series of interconnected computing devices, each including at least one or more computer processors (e.g., hardware processors, such as CPUs) that interoperate with computer memory. The interconnected computing devices include one or more physical computer servers, the physical computer servers configured for administering a security infrastructure and controlling access provisioning through the transmission of control signals through one or more network connections. The control signals are specially adapted for cryptographically secure network communications in accordance with one or more security protocols.

[0080] Access control, in some embodiments, is controlled through the specific generation, provisioning, and transmission of data structures representing identity certificates. These identity certificates are specially configured to maintain one or more data fields indicative of aspects that can be used to verify and validate the identity of the underlying computing device 130 and/or individual associated with the underlying computing device 130, and are processed in response to access provisioning requests, among others.

[0081] The identity certificates are digital certificates which include key information (e.g., public / private key pair information), and/or other information that aid in verification and validation. The digital certificates, in some instances, are issued by one or more certificate authority computing systems, which may be hierarchical in access provisioning, and the digital certificates themselves may be aggregates or combinations thereof including multiple certificates from the one or more certificate authority computing systems.

[0082] The security architecture is configured for securing communications with one or more remote security devices, which are introduced into the system at various (and often unknown) states of configuration. The security controller server is configured for establishing an unsecure connection for initial connection communications upon receiving initial connection communications from a security device over a default communication link 150 (e.g., a guest network). The system includes a network interface controller 104 that controls which of networks 150 or 160 is accessible by the security device 130.

[0083] The default communication link to network 150 can be coupled to a network or a subnetwork segregated from an secured network 160 or secured subnetwork requiring the network access certificate for communication. In such an embodiment, a guest network 150 is used for updating so that unauthorized device never communicates directly to a RADIUS server protecting production networks and devices. The default communication link enables communication to a computing device coupled to the certificate authority. In some embodiments, network 150 and network 160 are on the same network but are actually segregated subnetworks.

[0084] The default communication link, for example, may be a guest network or other type of segregated or sand-boxed network connection to maintain a level of protection against a potential malicious cyberattack. In some embodiments, the security architecture may require a heightened level of cybersecurity protocols that the new security device must adhere to (and must be updated to support) before any communications are possible with the secured elements of the security architecture (e.g., maintains a minimum level of security and encryption).

[0085] The initial connection communications include at least one device-identifying field and device configuration data, used to establish what the device is, and what the current state of the device is. The initial connection communications are processed by the security controller server, which receives the data packet and compares the at least one device- identifying field with a device access list, which defines devices permitted to access the system in a non-validated state. The comparison, in some embodiments, is based on a manually populated list. In alternate embodiments, an automatically maintained and generated list is utilized to dynamically track devices that are expected to be on-boarded onto the system (e.g., based on purchase orders, device requisitions, replacement schedules).

[0086] Upon verifying the security device is authorized for integration with the system based on the comparison, the security controller server (e.g., security compliance controller 106) is configured to determine a current firmware version (or kernel version) for the security device.

[0087] A process is initiated to securely update the out of date security device, whereby the security controller server, when the security device is out-of-date, sends the current firmware version (or kernel version) to the security device. A network access certificate is provisioned by transmitting a request to a certificate authority to generate a unique network access certificate for the security device based on at least one of the device-identifying fields, and the unique network access certificate is transmitted to the security device over an encrypted connection. In some embodiments, session-key based communication authentication mechanisms are provided by security device compliance controller 106 to be passed along as a secondary encryption layer to protect a protocol structure, ensuring that a protocol message is rotated along with the encryption, improving secured communications.

[0088] The security device compliance controller 106 securely updates the security device by transmitting operational settings to the security device, the operational settings and the current firmware version providing device configuration requirements required by system parameters to integrate with the system in a validated state, Operational settings can include other updates (not just firmware / kernel), and may, in some embodiments, include specifically configured biometric data, that is pre-loaded and adapted for a custom biometric configuration. Where there are vulnerabilities associated with hard coded keys, they may be deactivated and any keys being used are only those generated during installation and regular use (reducing a potential attack vector).

[0089] Default settings on the security device are de-activated or modified. For example, some devices had increased security features that are not enabled by default (e.g., to improve the ease of configuration / install). Accordingly, default passwords are removed and modified, and increased security features may be instilled (e.g., requiring administrator rights to access device programming). By instilling these additional security protocols, for example, default uses of clear text communication, increased security in relation to rights for access, can be provisioned.

[0090] Upon validating the security device for integration with the system, the security controller server transmits instructions to restart the security device with the current firmware and the transmitted operational settings, removes the security device from the device access list. Upon receiving a secure connection request from the security device including the unique network access certificate (e.g., adapted by custom certificate controller 102 operating in conjunction with a certificate generation engine 110), the security controller server permits the security device to integrate with the system in the validated state. In some embodiments, the network access certificate permits access to a RADIUS server coupled to the secured network or the secured subnetwork. Validation is conducted by a certificate validation engine 108, which as described in various embodiments, may authenticate against an entirety of the unique network access certificate or a selected portion of the unique network access certificate. The selected portion may vary depending on the level of security and a desired level of convenience (e.g., or an expected or total time required to conduct validation and verification).

[0091] In some embodiments, the unique network access certificate is a custom network authentication certificate augmented with one or more device-specific data fields indicative of one or more characteristics associated with the security device. [0092] The one or more characteristics stored within the custom network authentication certificate includes at least one of MAC addresses, kernel version, firmware version, available operational modes, traceroute, network connection types, device serial number, manufacturer identifier, available functionality, physical location, angular orientation, and technical specifications. In some embodiments, an improved integrity check is provided using additional / custom checksums (e.g., checksums at the end of a base level protocol), additional arbitrary message authentication code in the session key that is encrypted and validated server side). The improved integrity check aids in reducing the ability of an attacker to intercept traffic between the device and the application, if on the same network. [0093] The custom network authentication certificate is adapted to be processed to generate a compressed custom network authentication certificate for deployment to the security device, the compressed custom network authentication certificate storing a subset of the one or more device-specific data fields. The certificate authority server, responsive to a future authentication request from the security device, regenerates the custom network authentication certificate from the compressed custom network authentication certificate prior to authenticating the custom network authentication certificate for controlling access to the secured network or the secured subnetwork, thereby providing a stripped down custom certificate for pushing onto security device.

[0094] In some embodiments, the subset of the one or more device-specific data fields of the compressed custom network authentication certificate excludes one or more network connection-specific or location-specific fields that the certificate authority is able to determine based on analyzing characteristics of received communications from the security device. The subset of the one or more device-specific data fields of the compressed custom network authentication certificate includes one or more selected device-specific data fields based on one or more data storage constraints of the security device.

[0095] In some embodiments, the compressed custom network authentication certificate is transmitted to the security device in a series of ordered packets spaced temporally to manage transmission load across the encrypted connection in order to reduce peak network congestion loads and/or ensure ordinality in received information such that information that is not sent or acknowledged may be resent over a period of time. [0096] In some embodiments, the security infrastructure is designed to maintain "trust on first use" principles, whereby the custom network authentication certificate establishes a trusted connection based on characteristics of the security device during initial registration of the security device on the certificate authority. [0097] However, the custom network authentication, through each of the incorporated characteristics, may extend the kill chain to unmanageable or impractical levels of complexity. Accordingly, in an improved embodiment, the certificate authority is configured to tolerate deviation up to a threshold deviation from the one or more device-specific data fields when controlling access to the secured network or the secured subnetwork. Through the deviation tolerance, the system is configured to handle some level of deviation from the original set up (e.g., angles of device shift over time as walls shift of the building), yet flag or disable connections where the deviation threshold has been reached.

[0098] The certificate authority, responsive to a communication request from the security device where the deviation is greater than the threshold deviation, revokes the custom network authentication certificate and requires re-registration of the security device. The threshold deviation can be dynamically determined by the certificate authority based on at least on a security level enforcing a intrusion kill chain model wherein a minimum number of security validation steps are required in validating any access to the secured network or secured subnetwork. [0099] In some embodiments, the unique network access certificate includes a first portion storing a leaf node certificate and a second portion storing an encryption key associated with the leaf node certificate; and wherein the at least one processor of the system is configured to reconstitute a full chain certificate from the leaf node certificate and the encryption key, the full chain certificate being provided to the security device. A leaf node is a terminal node of the hierarchical structure of the certificate authorities.

[00100] The leaf node certificate, the encryption key, and the full chain certificate are stored in one or more memory locations on a secured server accessible by the certificate authority. In some embodiments, the one or more memory locations on the secured server are transformed into one or more metadata fields stored in one or more memory locations on an access control server. Storing only the leaf node certificate enables a reduction in stored information, allowing for more compact data structures to be utilized.

[00101] In an embodiment, the at least one processor is further configured for checking against security device templates by flagging the security device as unsafe and insecure upon a determination that the firmware version of the security device is out of date; controlling the security device to encapsulate and transmit to the system a data payload including one or more data sets representative of the at least one device-identifying field and the device configuration data; and wherein the verifying of the security device for authorization for integration includes at least validating the data payload by comparison with a security device template residing on the one or more servers for controlling device integration with the system.

[00102] In another embodiment, the custom network authentication certificate is utilized to generate a first certificate and a second certificate, the first certificate encrypting the custom certificate using a first encryption mechanism, and the second certificate encrypting the custom network authentication certificate using a second encryption mechanism, the first certificate and the second certificate both transmitted to the certificate authority for authentication such that at least one of the first certificate and second certificate are utilizing an encryption mechanism accepted by the certificate authority. The two certificates are used in a transitionary period, for example, during renewals as a bridge, or where there is a transition between protocols or multiple protocol servers in use simultaneously.

[00103] In some embodiments, the certificate authority periodically controls the system to generate a new custom network authentication certificate, the new custom network authentication certificate based on characteristics of the security device during periodic registration of the security device on the certificate authority. The periodic custom network authentication certificates aid in establishing trust on re-registration, whereby the first certificate is used until expiry, then the system switches over to new certificate, and the deviations from the custom certificate are measured against the new custom certificate.

[00104] FIG. 1 B shows aspects of an example system 100 to which aspects of the present disclosure may be applied. In some embodiments, the system 100 includes one or more servers, such as the "BioConnect Server", which are configured to control device integration with the system. In some embodiments, the system 100 may secure communications between the system and a remote network device such as a biometric, loT or physical control access device. Some embodiments may provide a certificate/key management system to authenticate network devices into a physical network. In some embodiments, the system may leverage DHCP (Dynamic Host Configuration Protocol), Active Directory, Radius Server and multiple advanced network security tools (such as TLS, PKI, OSDP, SHA 1/SHA 2 etc.).

[00105] In some embodiments, the system can be physically and/or logically classified into three layers: a Device Layer, a Core Layer and a Plug-in Layer. In some embodiments, the Device Layer is a lowest layer in the system which can be configured to interact with network devices, informing the devices of which protocol will be used to establish the data communication. In some embodiments, one or more security devices may be configured to host other devices. For example, an access control panel may host a smart reader/device such as a biometric device. In some embodiments, a smart reader may host a card reader or other basic device. In other embodiments, access control panels, smart readers/devices, and card readers/basic devices may operate in other configurations. In some embodiments, a first device may host a second device in the Device Layer through a secure communication channel. For example, the communication channel may be based on the OSDP protocol. In some embodiments, the devices may operate in a master-slave configuration. In some protocols, data stored on a device is encrypted to reduce the risk of attacks.

[00106] In some instances, the use of host devices in the Device Layer may provide the integration of a wider range of devices, including devices which may not have sufficient hardware or other capabilities to have a direct connection with the server(s). In some embodiments, the Core Layer is a middleware and can include a certificate/key management system. As shown in FIG. 1 B, the example system 100 can be configured to verify inputted user biometrics and may utilize Active Directory Service, Access Control Management (ACM) Service, and Access Control Panel to provision access. In some embodiments, one or more servers can operate or include a system certificate authority. In some embodiments, all devices (biometric/non biometric/smart/basic) will need to acquire certificates issued by the server(s) to gain validated access to the system. In some embodiments, the system includes a Plug-in Layer which can facilitate communication with APIs, identity databases and/or SDKs for validating or otherwise utilizing biometric or loT information inputted or detected at a security device.

[00107] FIG. 2 shows aspects of an example system 200 including examples of protection features which can, in some embodiments, be provided over different connections in the system.

ACM Shield [00108] In some embodiments, an Access Control Management (ACM) protections can be implemented between an Application Server and ACM (Access Control Management) Database in an effort to protect system integration (database integration, SDK integration and API integration) from cyber-attacks by leveraging security protocols such as the example protocols below:

[00109] In some embodiments, third party APIs and SDKs may be evaluated before integration to ensure all third party components meet the system's security standards.

[001 10] In some embodiments, minimum system security standards can include: - WCF (Windows Communication Foundation): two way minimum TLS 1 .2 with SHA2 256 and above.

- Restful JSON: two way minimum TLS 1 .2 with SHA2 256 and above.

- In Process Protection Two Mechanism: o Encrypted memory with code obfuscation and code signing & . DLL signing. o Fuzzy logic applied to data objects in memory. Communication Shield

[0011 1] Communications can be classified into four categories: Device to Application, Device to Panel, Device to Device, and ACM to Application.

> Device to Application

[00112] In some embodiments, SHA1/SHA2 (Secure Hash Algorithm 1/2) collaborates with TLS (Transport Layer Security) to protect the device to application communication channel. TOFU (Trust on First Use) is a security model which can be utilized to establish the initial connection between the biometric devices and BioConnect Server. In this model, active toggle (customer has ability to toggle function) inside BioConnect Server will prevent any device operation until the operator/system confirms its authenticity. In some embodiments, once the initial connection is established, BioConnect Server will send TLS and/or 802.1x certificates (e.g. X509 with SHA256) to the biometric reader to secure and/or authenticate communications with the reader. In some embodiments, one or more certificates can be used for authentication with a customer radius server. In some embodiments, radius server authentication can occur after a whitelisted device has been validated and is prevented from accessing the network in a non-validated state. [00113] In some embodiments, penetration tests or equivalent can be used to validate device (firmware) integrity before working with the application. The system can be configured to erase device memory to minimize the risk of possible embedded malware attack. In some embodiments, penetration tests can include firmware and/or physical device tests, for example, a device with an exposed reset pinhole on an unsecured side of a door will fail a penetration test. In some embodiments, devices with such security deficiencies may be blocked from integrating with the system, for example, by including corresponding device identifiers on a system access blacklist.

[00114] In some embodiments, secure communications between the device and server can utilize OpenSSL. In other embodiments, ECDSA or RSA encryption standards may be used.

> Device to Panel

[00115] OSDP (Open Supervised Device Protocol) Secure channel (2.1.5 and above) can be implemented within the Device to Panel Communication Shield to replace traditional Wiegand protocol in order to enhance the communication security. By leveraging OSDP, a biometric device can act as a slave or a host to the access control panel. All data being transmitted between/ stored on devices can be encrypted to minimize the risk of cyber- attacks.

[00116] For systems that do not support industry standards such as Wiegand or OSDP, the following example authentication strategies can be implemented to ensure device to panel security:

Authentication Strategy Application

SHA 256 / HMA C256 • Network only ACM Channel

• Device operating with equalization

• IOT, Web Based Application, Client-

Windows AD

Server Application, Database Communications

• Typical ACM Systems or other Access

RFID, PINs, etc. Control Based System

• Authentication Practices for Vendors that have Centralized Databases

• BioConnect ID

Biometrics • Any other BioConnect handled systems

& devices that do not have centralized Database and rules for operation > Device to Device

[00117] In some embodiments, Device to Device Communication Shield can utilize or require a minimum TLS 1.2 with SHA256 for certificates to ensure the communication security between network enabled devices. Non-network enabled devices, in some embodiments, cannot maintain user data but only operate in a "pass-through" context to the biometric reader or application.

[00118] In some instances, penetration tests or equivalent can be used to validate device (e.g. firmware and/or kernel) integrity before working with other devices.

> ACM to Application

[00119] The use of traditional hard-coded cryptographic keys can greatly increase the possibility that encrypted data may be recovered by malicious users. In some embodiments, ACM to Application Shield leverages a SDK Signing technique which does not contain any hardcoded encryption keys and file writing functions to offer user inherent protection against memory leaks/injections, SQL injections, and process override.

[00120] To further enhance the system security, in some embodiments, the following features can be included: - Obfuscation to be used on all .dlls files

Penetration test to confirm peripheral ports are not open

SDK releases require penetration testing and subsequent Kernel or Firmware releases if relevant

SDK will run as independent process or micro-service for security insulation and resiliency

Network Shield [00121] Similar to the Device to Application shield, in some embodiments, the Network Shield can leverage TOFU and active toggle techniques to establish the initial device to network connection. After that, the customer or other RADIUS (Remote Authentication Dial- In User Service) server can continue to authorize a biometric reader's access to the network by verifying 802.1x certificates issued by the server(s).

[00122] In some embodiments, custom certificate authorities can be used with a chain depth of 2 or up to 110.

[00123] In some embodiments, the Network Shield may utilize one or more of the following communication standards: - Wpa_supplicant for Linux based Systems

Windows Network Infrastructure

Minimum TLS 1.2 for SHA 256 between the network and the device - TTLS or Point to Point Protocol

Computer Authentication or User Authentication with PKI in place Hardware Shield

[00124] In some embodiments, when equipped with Hardware Shield, network devices may be less likely to suffer from direct physical attack. In some embodiments, a tamper mode will be activated when unauthorized operation occurs. In this scenario, all data will be removed from the device, preventing attacker from launching further cyber-attacks by acquiring the data from physical devices.

Migration Shield (Resiliency Shield)

[00125] In some embodiments, a Migration Shield (or Resiliency Shield) serves to provide network resilience or the ability to maintain an acceptable level of service in the face of faults and challenges to normal operation. [00126] In some embodiments, leveraging nsjookup (name server lookup), biometric devices can intelligently locate and connect with a failover server when a main server is unavailable, for example, due to natural disaster or targeted attack. In the meantime, the system may send outage notifications to alert operators to the system malfunction. [00127] In some embodiments, an IPV6 and IPV4 dual stack technique allows biometric devices to detect the internet protocol and switch between IPV6 and IPV4 to complete Socket Connection with BioConnect SDK. The readers may also devise socket logic that allows the reader to disconnect or reconnect based on the internet protocol available to the reader. [00128] FIG. 3 is a flowchart showing aspects of an example method for securing communications with a remote security device. In some embodiments, aspects of the method may be performed by one or more servers for controlling device integration with the system. In some embodiments, the server(s) include one or more processors,

[00129] At 302, the processor(s) receive initial connection communications from security device. In some embodiments, the initial connection communications may include a hello command, a connection request, and/or any other message involved in a communication initiation protocol. In some embodiments, the initial connection communications may be over a default communication link such as a TCP/IP link. In some embodiments, the default communication link may be unsecured or may have limited security features/protocols. [00130] In some embodiments, the initial connection communications can include one or more messages. In some embodiments, these messages may include one or more device identifying fields as well as device configuration data.

[00131] In some embodiments, device identifying fields can include a MAC address, device IP address, port, serial number and/or any other field which can potentially be used to identify the device.

[00132] In some embodiments, device configuration data can include a MAC address, firmware version, kernel/OS version, device type, software core version, and/or the like. [00133] In some embodiments, the processors may determine whether the device hardware is capable of providing and/or implementing the necessary security requirements of the system before granting access.

[00134] At 304, the processor(s) compare one or more of the device-identifying fields with one or more device access lists. In some embodiments, the device access lists are controlled by a system administrator. In some embodiments, the device access lists can include whitelists and/or blacklists. In some instances, a system administrator will add device-identifying fields to a device access list when informed that a device is to be added to the system. [00135] In some embodiments, when the processors determine that the device is authorized for integration and/or has suitable hardware capabilities, the processors permit the device to access the system in a non-validated state. In some embodiments, in a non- validated state, the device connects to the servers on a different network connection than devices in a validated state. In some embodiments, this may allow the device to be brought into compliance while protecting system access, resources and data from the non-validated device.

[00136] Upon verifying the security device is authorized for integration with the system based on the comparison of the device-identifying fields and the device access lists, the processor(s) determine whether the device is up-to-date. For example, in some embodiments, the processor(s) can determine whether the device's firmware, kernel and/or configuration settings are up-to-date with current system security requirements based on one or more system databases.

[00137] At 306, when the device is determined to be out-of-date, the processors send current firmware, kernel, OS, etc. to the device. [00138] In some embodiments, the system forces the device to install the firmware, etc. and/or to clear its memory to eliminate any potential previously installed malware or undesired code. [00139] At 308, the processors transmit a request to a certificate authority to generate a unique network access certificate for the security device. In some embodiments, the network access certificate is based on one or more of the device-identifying fields. In some embodiments, each generated network access certificate is unique to a single corresponding device. In this manner, in some instances, access to the system can be revoked on a device-by-device basis.

[00140] In some embodiments, the certificate may be a certificate for 802.1X and/or TLS/SSL connections.

[00141] In some embodiments, the certificate may be generated based on a customer root certificate.

[00142] At 310, the processors transmit the device-specific network access certificate to the device. In some embodiments, the processors also transmit operational settings to the device. In some embodiments operational settings may include communication parameters/protocols for connecting in a validated state, which and how many authentication factors are required for a biometric device (e.g. card, fingerprint, retina scan), etc.

[00143] In some embodiments, the processors establish an encrypted connection to transmit the certificate and/or operational settings.

[00144] In some embodiments, before the processors permit the device to integrate with the system in a validated state, the processors may wait for a validation trigger. In some embodiments, a validation trigger may be triggered when all updates and settings have been installed on the device with requirement minimum hardware capabilities. In some embodiments, the processors may wait for an input associated with an administrative account which authorized the validation of the device.

[00145] At 312, the processors transmit instructions to cause the security device to restart. In some embodiments, this forces the security device to begin operating with newly pushed firmware, certificates, clear memory and/or operational settings. [00146] At 314, the processors update the device access list(s) to no longer enable the device to connect with the servers over the default communication link.

[00147] At 316, the processors receive a secure connection request from the restarted security device. In some embodiments, the secure connection request includes the unique network access certificate or a signature or other token based on the network access certificate.

[00148] Upon verification of the authenticity of the token, the processors permit the security device to integrate with the system in a validated state.

[00149] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

[00150] FIG. 4 is a schematic diagram of a computing device 400 such as a server. As depicted, the computing device includes at least one processor 402, memory 404, at least one I/O interface 406, and at least one network interface 408.

[00151] Processor 402 may be an Intel or AMD x86 or x64, PowerPC, ARM processor, or the like. Memory 404 may include a suitable combination of any type of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), or the like.

[00152] Each I/O interface 406 enables computing device 400 to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, or with one or more output devices such as a display screen and a speaker.

[00153] Each network interface 408 enables computing device 400 to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including any combination of these.

[00154] Computing device 400 is operable to register and authenticate users (using a login, unique identifier, and password for example) prior to providing access to applications, a local network, network resources, other networks and network security devices. Computing devices 400 may serve one user or multiple users. [00155] FIG. 5 is a process diagram of a process for establishing a certificate for a physical access security device, according to some embodiments.

[00156] As shown in this diagram, Applicants have developed a system that automatically installs x.509/802.1x certificates onto devices using Microsoft PowerShell™. The solution provides operators with the ability to, in a single process, request, generate and install an x.509/802.1x certificate on a selected device. The 802.1x certificate, once installed, provides device and port level access control and encryption between endpoints. PowerShell™, in this instance, acts as a proxy for the API to a secured system, by not allowing the system application direct access to the Certificate Generation API.

[00157] Steps of the implemented solution include receiving a request from the client application to a local SAS Server to install a new Certificate by passing the ID and MAC Address of the Device to the SAS Server. The SAS Server passes the MAC address of the device to the PowerShell Script, and the PowerShell Script requests a new Certificate from the Certificate Generator by passing it the MAC address.

[00158] The Certificate Generator uses AD (Active Directory) to validate the request and returns a Leaf Node Certificate. It also generates the Encryption Key for the Certificate. The Leaf Certificate and Key are returned to the PowerShell Script where it is reconstituted by the PowerShell Script into a full Chain Certificate. To do this, the PowerShell Script uses the Root CA (Certificate Authority) and any requisite intermediate CAs to generate a full Certificate Chain. The Key, Leaf Certificate and Chain Certificate are placed into a folder specified by the secured infrastructure.

[00159] A JSON file is returned by the PowerShell™ script to the SAS server containing the file names and paths to each of the three aforementioned elements. The server parses and validates the full Chain Certificate and stores its metadata in the SAS database. The SAS Server pushes the Chain Certificate and the Key to the Device where the Device installs the Certificate.

[00160] The JSON file includes a:

• Path and name of the Key file · Path and name of the Leaf Certificate file

• Path and name of the full certificate containing the Root CA file

[00161] The application uses the information in the JSON structure to locate the three files.

[00162] In sequence, the application loads each of the two Certificate files into memory and parses them to ensure that they are formatted correctly as x.509 certificates. If validated, the certificate metadata is stored in the database. A new row is created in a Certificates table containing the certificate metadata and the ID of the new row is returned. The IsActive flag is also set to false for the new row. A query is run to set the IsActive flag to false for all Certificates associated with the DevicelD, except for the newly inserted row.

[00163] The application pushes the newly retrieved Certificate and Key to the selected device, the device installs the Certificate and returns confirmation of the installation. The Server returns confirmation of a successful Certificate installation to the Client application. The Client application ID updates with the new Certificate status.

[00164] FIG. 6 shows two example processes for establishing TLS certificates and 802.1x certificates, according to some embodiments. [00165] FIG. 7A is an example data structure diagram of an example custom certificate, according to some embodiments.

[00166] A custom certificate is a unique network access certificate that is generated for the security device by a certificate authority or a access controller mechanism. The custom certificate is a downloadable payload that is dynamically generated to provision access to a remote security device for secured communications with a backend. For example, the remote security device could be a card reader that controls access to a server cabinet such that administrators are able to conduct routine maintenance.

[00167] Certificates are often issued after verification of the identity, and in some embodiments, the custom certificates are seeded or otherwise populated with additional fields and information based on the initial configuration of the remote security device and/or its network access pathway during the first use / registration (e.g., "trust on first use"). The custom certificates are often associated with a period of validity, and may expire or become automatically revoked upon the expiry of this time period. The custom certificate may include various pairs of keys, such as private and public keys, and the custom certificate can be verified against the public keys exposed by one or more certificate authorities.

[00168] Accordingly, the certificate authorities and their public keys may be utilized to verify the authenticity of the remote security device for downstream connections and information transfers, including access provisioning requests and grants / denials of same. [00169] TOFU (Trust on first use) serves as an extra layer of security when connecting devices to an application server. TOFU for example, may utilize the interaction of an administrator in order to enable a newly added device to receive the designated certificates and establish a secure connection with the application server. The administrator would be able to identify devices that have connected to the server but have yet to be authorized to communicate fully with the secure areas of the software.

[00170] Devices would be identified on these lists using MAC address, device ID and other unique values that would identify a particular device. The administrator would acknowledge that a specific device or devices are authorized to receive the secure certificates and then establish secure connection to the application server. Establishing blind trust to any device being connected to the network creates an opportunity for rogue devices to be introduced into the network and gain access to unauthorized network and application servers.

[00171] A main reason to implement a TOFU feature is to prevent rogue devices from trying to gain access to the application server. If an attacker were to attempt to gain access to the application server or the network, this would be gated by software administrators having to allow the device onto the network. Software administrators would be able to easily identify a device that was not recently connected to the network and refuse the device's connection to the server. An attacker could attempt to mimic the representation of a device on the network but would have to trigger an authorization within the actual application server in order for the device to begin communicating with the device. An attacker could also gain access to unused devices already configured for access to the network, upon attempting to place that device onto the network, they would be stopped as TOFU security would force administrators to allow that device onto the network. [00172] TOFU, in some embodiments, is incorporated into the fields of the certificate attributes to track one of more attributes of the security device or the network access connections associated with the security device thereof.

[00173] These attributes brought into the certificate result in a greater level of protection than that of ordinary certificates, and are incorporated during the initialization and on- boarding process, and may include characteristics of an installation, a network access connection type, etc. The customized fields can also be client / security infrastructure specific, so that an attacker armed only with a pre-existing knowledge of the security device characteristics (e.g., default passwords for a reader, default settings for a reader) is unable to breach the system. [00174] For example, a custom certificate could have a first set of custom fields for additional security features associated with the security device including an additional checksum, a manufacturing date of the device, a shipping date of the device, a date of first connection of the device, an indication of firmware version, kernel version, an angular orientation (e.g., as measured by an onboard gyroscope), a GPS location (e.g., as measured by triangulation), an altitude off of a ground (e.g., as measured by a rangefinder). An organization can pick and choose which custom fields to include, and the custom fields are managed and inserted into the certificate by system 100, and the certificate validation engine 108 is adapted to validate access based on the custom fields. [00175] A second set of custom fields 702B may be generated based off of characteristics of the network access point (e.g., network DNS, gateway IP address, port number for communications, physical port number of a wired connection into a router, connection speed, connection latency, traceroute intermediary communication points, wireless 802.1x band, network access point access credentials). These fields can be updated or set during first use or renewal, and accordingly, would be unknown to an assailant without specific knowledge of the system. Fields 704 may be standard fields in a certificate (e.g., a certificate, keys, chains, etc.).

[00176] Accordingly, if a specific endpoint were compromised by an assailant, serious certificate and security infrastructure would have to be done at the device level. Depending on where the breach occurred, this could amount to a complete rebuilding of a portion of their security infrastructure. Implementing TOFU can seriously decrease the impact of a breach in terms of downtime and complexity. TOFU allows administrators to target and identify the areas of the system effected and easily remove and replace the impacted sections of the physical security infrastructure without having to perform more widespread changes to the system.

[00177] In a specific example, if an assailant takes the reader off the wall, compromises it by physical tampering and replaces it, it may be at a crooked angle, and the certificate, despite being the same certificate, may end up being rejected by certificate validation engine 108. Similarly, if an assailant takes the reader off the wall and attaches it at a different network access point, it will also be rejected by certificate validation engine 108.

[00178] FIG. 7B is an example of a truncated data structure used for a truncated custom certificate, according to some embodiments. [00179] The application server truncates the custom certificate information in order to guarantee that all the certificate data is transferred down to the device. If any part of the certificate data were missing from the device, it would not be able to establish a secure connection to the application server. Truncating the certificate decreases the chances that all or some of the certificate data is missing when sent down to the reader.

[00180] If certificate data on the device were incomplete or corrupted, the device would not be able to communicate with the application server. This device would then have to be manually reset so that all certificate data be removed from the device. The sections of the certificate that are truncated and sent down to the device include the certificate, certificate key and certificate chain. These are sent down separately.

[00181] The data threshold is 1420 bytes, by breaking the data down to packets this size or smaller, the system ensures data integrity from the application Server down to the device. The truncated certificates are sent down in a specific order.

[00182] Certificate chain is sent down first, followed by certificate and finally the certificate key. The certificate key will use the existing data on the device (certificate chain and certificate) to initiate and authorize identification with the server. The device requires a minimum certificate key value of 4096 bytes of data in order to enable communication with the server.

[00183] If the device were to not have the minimum of 4096 bytes for the certificate key then this would signify that the certificate data on the device is incomplete or corrupted.

[00184] The truncation of the data structure can also improve security. For example, if only part of the customizable certificate is provided to be stored on on-board memory of the device 130, such as 702A, the second part of the customizable certificate 702B may be reconstituted by system 100 prior to validation by validation engine 108. An assailant stealing or spoofing certificates stored on-board on the device 130 and using them elsewhere in the network will still face rejections by certificate validation engine 108 as the network characteristics, upon reconstitution of the full custom certificate by system 100, will be incorrect and thus lead to rejection by the certificate validation engine 108. In FIG. 7B, fields 706 are truncated and not sent to the security device 130.

[00185] FIG. 7C is an example of a data structure used for a custom certificate that is adapted to allow the system to tolerate a level of deviation 712, according to some embodiments.

[00186] The application server and/or the certificate authorities may be configured to ignore certain sections of the certificate to enable for more deviation and differences between certificates on the server and the devices. The number and selection of the sections of the certificate that can be ignored may be based on a security level associated to access device by the certificate authority. For example, the deviation tolerance may be higher for a lower security access provisioning, and lower for a higher security access provisioning.

[00187] Tolerance is an important consideration, as the custom certificate, in validated in its entirety, can be overly burdensome from a validation perspective, especially if the custom fields include values that require certificate validation engine 108 to conduct further computations (e.g., checksums, hashes, other error detecting codes).

[00188] By providing a system 100 whereby the portion of the custom certificate used for validation can be dynamically re-sized, the computational burden can also thus be re-sized and selected based on the particular application and security level of the access device 130.

[00189] In some embodiments, instead of ignoring specific fields, deviation tolerance may be established based on a total deviation score 710 that is generated from an aggregate of custom certificate field deviation scores 708, in concert. While the computational burden may still be present, a deviation tolerance based on deviation scores, in concert, may allow for increased flexibility on implementation.

[00190] An example of deviation tolerance may be, for example, an SSID of the network being slightly different than that expected on the certificate (having different capitalization), the security device being somewhat crooked in mounting relative to when it was first mounted (e.g., due to minor shifts in the building foundation), a different TLS standard being used, among others. While a small total deviation may be tolerated, a larger total deviation may lead to access being denied at 714.

[00191] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof. [00192] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[00193] The term "connected" or "coupled to" may include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements).

[00194] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (e.g. personal computer, server, virtual environment, cloud computing system, network device) to execute the methods provided by the embodiments.

[00195] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements. The embodiments described herein are directed to electronic machines and methods implemented by electronic machines adapted for processing and transforming electromagnetic signals which represent various types of information.

[00196] The embodiments described herein pervasively and integrally relate to machines, and their uses; and the embodiments described herein have no meaning or practical applicability outside their use with computer hardware, machines, and various hardware components. Substituting the physical hardware particularly configured to implement various acts for non-physical hardware, using mental steps for example, may substantially affect the way the embodiments work.

[00197] Such computer hardware limitations are clearly essential elements of the embodiments described herein, and they cannot be omitted or substituted for mental means without having a material effect on the operation and structure of the embodiments described herein. The computer hardware is essential to implement the various embodiments described herein and is not merely used to perform steps expeditiously and in an efficient manner.

[00198] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the scope. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.

[00199] As one of ordinary skill in the art will readily appreciate from the disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps. [00200] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Claims

WHAT IS CLAIMED IS:

1. A system for securing communications with remote security devices, the system comprising:

one or more servers for controlling device integration with the system, the one or more servers comprising at least one processor configured for:

receiving initial connection communications from a security device over a default communication link, the initial connection communications including at least one device-identifying field and device configuration data;

comparing the at least one device-identifying field with a device access list defining devices permitted to access the system in a non-validated state;

upon verifying the security device is authorized for integration with the system based on the comparison, determining a current firmware version for the security device;

the security device is out-of-date, sending the current firmware version to the security device;

transmitting a request to a certificate authority to generate a unique network access certificate for the security device based on at least one of the device- identifying fields;

transmitting the unique network access certificate to the security device over an encrypted connection;

transmitting operational settings to the security device, the operational settings and the current firmware version providing device configuration requirements required by system parameters to integrate with the system in a validated state;

upon validating the security device for integration with the system:

transmitting instructions to restart the security device with the current firmware and the transmitted operational settings;

removing the security device from the device access list;

receiving a secure connection request from the security device including the unique network access certificate; and

permitting the security device to integrate with the system in the validated state.

2. The system of claim 1 , wherein the default communication link is coupled to a network or a subnetwork segregated from an secured network or secured subnetwork requiring the network access certificate for communication.

3. The system of claim 2, wherein the default communication link enables communication to a computing device coupled to the certificate authority.

4. The system of claim 3, wherein the unique network access certificate permits access to a RADIUS server coupled to the secured network or the secured subnetwork.

5. The system of claim 1 , wherein the unique network access certificate is a custom network authentication certificate augmented with one or more device-specific data fields indicative of one or more characteristics associated with the security device.

6. The system of claim 5, wherein the one or more characteristics includes at least one of MAC addresses, kernel version, firmware version, available operational modes, traceroute, network connection types, device serial number, manufacturer identifier, available functionality, physical location, angular orientation, and technical specifications.

7. The system of claim 5, wherein the custom network authentication certificate is processed to generate a compressed custom network authentication certificate for deployment to the security device, the compressed custom network authentication certificate storing a subset of the one or more device-specific data fields; and wherein the certificate authority, responsive to a future authentication request from the security device, regenerates the custom network authentication certificate from the compressed custom network authentication certificate prior to authenticating the custom network authentication certificate for controlling access to the secured network or the secured subnetwork.

8. The system of claim 7, wherein the subset of the one or more device-specific data fields of the compressed custom network authentication certificate exclude one or more network connection-specific or location-specific fields that the certificate authority is able to determine based on analyzing characteristics of received communications from the security device.

9. The system of claim 7, wherein the subset of the one or more device-specific data fields of the compressed custom network authentication certificate includes one or more selected device-specific data fields based on one or more data storage constraints of the security device.

10. The system of claim 9, wherein the compressed custom network authentication certificate is transmitted to the security device in a series of ordered packets spaced temporally to manage transmission load across the encrypted connection.

11. The system of claim 5, wherein the custom network authentication certificate establishes a trusted connection based on characteristics of the security device during initial registration of the security device on the certificate authority.

12. The system of claim 1 1 , wherein the certificate authority is configured to tolerate deviation up to a threshold deviation from the one or more device-specific data fields when controlling access to the secured network or the secured subnetwork.

13. The system of claim 12, wherein the certificate authority, responsive to a communication request from the security device where the deviation is greater than the threshold deviation, revokes the custom network authentication certificate and requires re-registration of the security device.

14. The system of claim 1 1 , wherein the threshold deviation is dynamically determined by the certificate authority based on at least on a security level enforcing a intrusion kill chain model wherein a minimum number of security validation steps are required in validating any access to the secured network or secured subnetwork.

15. The system of claim 1 , wherein the unique network access certificate includes a first portion storing a leaf node certificate and a second portion storing an encryption key associated with the leaf node certificate; and wherein the at least one processor of the system is configured to reconstitute a full chain certificate from the leaf node certificate and the encryption key, the full chain certificate being provided to the security device.

16. The system of claim 15, wherein the leaf node certificate, the encryption key, and the full chain certificate are stored in one or more memory locations on a secured server accessible by the certificate authority.

17. The system of claim 16, wherein the one or more memory locations on the secured server are transformed into one or more metadata fields stored in one or more memory locations on an access control server.

18. The system of claim 15, wherein the unique network access certificate further includes one or more additional intermediate certificates, each intermediate certificate controlling access through one or more corresponding intermediate certificate authorities, and wherein the certificate authority and the one or more intermediate certificate authorities are configured in a hierarchical model where the certificate authority has control over all intermediate certificate authorities, and each intermediate certificate authority has control over any intermediate certificate authorities residing below on the hierarchical model.

19. The system of claim 1 , wherein the at least one processor is further configured for: flagging the security device as unsafe and insecure upon a determination that the firmware version of the security device is out of date;

controlling the security device to encapsulate and transmit to the system a data payload including one or more data sets representative of the at least one device- identifying field and the device configuration data; and

wherein the verifying of the security device for authorization for integration includes at least validating the data payload by comparison with a security device template residing on the one or more servers for controlling device integration with the system.

20. The system of claim 5, wherein the custom network authentication certificate is utilized to generate a first certificate and a second certificate, the first certificate encrypting the custom certificate using a first encryption mechanism, and the second certificate encrypting the custom network authentication certificate using a second encryption mechanism, the first certificate and the second certificate both transmitted to the certificate authority for authentication such that at least one of the first certificate and second certificate are utilizing an encryption mechanism accepted by the certificate authority.

21. A computer implemented method for securing communications with remote security devices, the method comprising:

comparing the at least one device-identifying field with a device access list defining devices permitted to access a secured system in a non-validated state; upon verifying the security device is authorized for integration with the system based on the comparison, determining a current firmware version for the security device; the security device is out-of-date, sending the current firmware version to the security device;

upon validating the security device for integration with the system:

removing the security device from the device access list;

22. The method of claim 21 , wherein the default communication link is coupled to a network or a subnetwork segregated from an secured network or secured subnetwork requiring the network access certificate for communication.

23. The method of claim 22, wherein the default communication link enables communication to a computing device coupled to the certificate authority.

24. The method of claim 23, wherein the unique network access certificate permits access to a RADIUS server coupled to the secured network or the secured subnetwork.

25. The method of claim 21 , wherein the unique network access certificate is a custom network authentication certificate augmented with one or more device-specific data fields indicative of one or more characteristics associated with the security device.

26. The method of claim 25, wherein the one or more characteristics includes at least one of MAC addresses, kernel version, firmware version, available operational modes, traceroute, network connection types, device serial number, manufacturer identifier, available functionality, physical location, angular orientation, and technical specifications.

27. The method of claim 25, wherein the custom network authentication certificate is processed to generate a compressed custom network authentication certificate for deployment to the security device, the compressed custom network authentication certificate storing a subset of the one or more device-specific data fields; and wherein the certificate authority, responsive to a future authentication request from the security device, regenerates the custom network authentication certificate from the compressed custom network authentication certificate prior to authenticating the custom network authentication certificate for controlling access to the secured network or the secured subnetwork.

28. The method of claim 27, wherein the subset of the one or more device-specific data fields of the compressed custom network authentication certificate exclude one or more network connection-specific or location-specific fields that the certificate authority is able to determine based on analyzing characteristics of received communications from the security device.

29. The method of claim 27, wherein the subset of the one or more device-specific data fields of the compressed custom network authentication certificate includes one or more selected device-specific data fields based on one or more data storage constraints of the security device.

30. The method of claim 29, wherein the compressed custom network authentication certificate is transmitted to the security device in a series of ordered packets spaced temporally to manage transmission load across the encrypted connection.

31. The method of claim 25, wherein the custom network authentication certificate establishes a trusted connection based on characteristics of the security device during initial registration of the security device on the certificate authority.

32. The method of claim 31 , wherein the certificate authority is configured to tolerate deviation up to a threshold deviation from the one or more device-specific data fields when controlling access to the secured network or the secured subnetwork.

33. The method of claim 32, wherein the certificate authority, responsive to a communication request from the security device where the deviation is greater than the threshold deviation, revokes the custom network authentication certificate and requires re-registration of the security device.

34. The method of claim 31 , wherein the threshold deviation is dynamically determined by the certificate authority based on at least on a security level enforcing a intrusion kill chain model wherein a minimum number of security validation steps are required in validating any access to the secured network or secured subnetwork.

35. The method of claim 21 , wherein the unique network access certificate includes a first portion storing a leaf node certificate and a second portion storing an encryption key associated with the leaf node certificate; and wherein the at least one processor of the method is configured to reconstitute a full chain certificate from the leaf node certificate and the encryption key, the full chain certificate being provided to the security device.

36. The method of claim 35, wherein the leaf node certificate, the encryption key, and the full chain certificate are stored in one or more memory locations on a secured server accessible by the certificate authority.

37. The method of claim 36, wherein the one or more memory locations on the secured server are transformed into one or more metadata fields stored in one or more memory locations on an access control server.

38. The method of claim 35, wherein the unique network access certificate further includes one or more additional intermediate certificates, each intermediate certificate controlling access through one or more corresponding intermediate certificate authorities, and

wherein the certificate authority and the one or more intermediate certificate authorities are configured in a hierarchical model where the certificate authority has control over all intermediate certificate authorities, and each intermediate certificate authority has control over any intermediate certificate authorities residing below on the hierarchical model.

39. The method of claim 21 , wherein the at least one processor is further configured for: flagging the security device as unsafe and insecure upon a determination that the firmware version of the security device is out of date;

controlling the security device to encapsulate and transmit to the method a data payload including one or more data sets representative of the at least one device- identifying field and the device configuration data; and

wherein the verifying of the security device for authorization for integration includes at least validating the data payload by comparison with a security device template residing on the one or more servers for controlling device integration with the method.

40. The method of claim 25, wherein the custom network authentication certificate is utilized to generate a first certificate and a second certificate, the first certificate encrypting the custom certificate using a first encryption mechanism, and the second certificate encrypting the custom network authentication certificate using a second encryption mechanism, the first certificate and the second certificate both transmitted to the certificate authority for authentication such that at least one of the first certificate and second certificate are utilizing an encryption mechanism accepted by the certificate authority.

41. A computer readable medium storing machine interpretable instructions thereon, the machine interpretable instructions, when executed, cause one or more processors to perform steps of a method of any one of claims 21-40.