WO2024259490A1

WO2024259490A1 - User authentication for operational technology (ot) assets

Info

Publication number: WO2024259490A1
Application number: PCT/AU2024/050651
Authority: WO
Inventors: Mohammad NOSOUHI; Zubair BAIG; Robin DOSS; Praveen Gauravaram; Debi Prasad PATI; Syed Shah; Lei Pan; Keshav SOOD; Divyans Mahansaria
Original assignee: Cyber Security Research Centre Limited
Priority date: 2023-06-23
Filing date: 2024-06-21
Publication date: 2024-12-26

Abstract

This disclosure relates to authenticating a user with an operational technology (OT) asset. An authentication server generates a token by: receiving a request for the token from a first user device communicatively coupled to a security device, the request comprising a proof-of-possession (PoP) public key of the security device and a signature calculated using a private key corresponding to a registration public key being registered with the authentication server; and generating the token. The OT asset then processes the token by: receiving the token from a second user device communicatively coupled to a security device; checking the signature of the token; sending a challenge to the second user device; receiving from the second user device a signature of the challenge calculated using the PoP private key and forming a key pair with the PoP public key; verifying the signature; and upon verification, authenticating the user with the OT asset.

Description

"User authentication for operational technology (OT) assets"

Technical Field

[0001] This disclosure relates to authenticating a user with an operational technology (OT) asset.

Background

[0002] OT assets are often programmable systems or devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems/devices detect or cause a direct change through the monitoring and/or control of devices, processes, and events. In other words, operational technology is hardware and software that detects or causes a change, through the direct monitoring and/or control of industrial equipment, assets, processes and events.

[0003] Examples of operational technology include:

• Programmable logic controllers (PLCs)

• Supervisory control and data acquisition systems (SCAD A)

• Distributed control systems (DCS)

• Computer numerical control (CNC) systems, including computerized machine tools

• Scientific equipment (e.g. digital oscilloscopes)

• Building Management System (BMS) and building automation systems (BAS)

• Lighting controls both for internal and external applications

• Energy monitoring, security and safety systems for the built environment

• Remote terminal units (RTU)

• Transportation systems for the built environment

[0004] One characteristic of OT assets is that, while they are operated and managed by users, they focus on the interaction with the physical environment rather than the interaction by a specific user. As such, OT assets often have no dedicated account or account with limited capability available for each user and do not hold user-specific data, such as user credentials, user names, access control lists, user files, preferences etc.

[0005] Nevertheless, maintenance technicians ought to be authenticated with the OT asset to prevent unauthorised users to disrupt operations. Therefore, this disclosure generally relates to securing access to critical assets (such as PLCs, RTUs, etc.) and applications (such as SCADA, human machine interface (HMI) and open platform communications (OPC) servers) deployed in an Industrial Control System (ICS). ICSs are a key component of most of Critical Infrastructure (CI) today. They enable automation of heterogeneous processes and services that run within a CI. However, convergence of conventional ICS resources and IT Systems and their transformation into modern connected systems through IIoT (Industrial loT) platform, expand the cyber-attack surface which poses serious impact on safety if security measures are not effectively considered during the transformation journey.

[0006] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

[0007] Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Summary

[0008] A method for authenticating a user with an operational technology (OT) asset comprises: an authentication server generating a token by: receiving a request for the token from a first user device being communicatively coupled to a security device, the request comprising a proof-of- possession (PoP) public key of the security device and a signature of the (PoP) public key calculated by the security device using a private key corresponding to a registration public key of the security device, the registration public key being registered with the authentication server; and generating the token comprising the PoP public key of the security device and a signature of the token calculated by the authentication server using a private key of the authentication server; the OT asset processing the token to authenticate the user by: receiving the token from a second user device being communicatively coupled to a security device; checking the signature of the token using the public key of the authentication server stored in the OT asset; sending a challenge to the second user device; receiving from the second user device a signature of the challenge calculated using the PoP private key stored in the security device and forming a key pair with the PoP public key; verifying the signature using the PoP public key of the security device in the token; and upon verification, authenticating the user with the OT asset.

[0009] It is an advantage that the OT asset can authenticate the user device by using the token as the only data from the authentication server. This way, the user can be authenticated even if the authentication server is offline. Therefore, the method provides a more robust solution compared to authentication by the server. At the same time, identity & access management of users and provisioning of OT assets is still performed centrally at the authentication server, which enables the flexible administration of a large number of OT assets without having to configure each user device with each OT asset individually. [0010] In some embodiments, generating the token is conditional on determining that the registration public key of the security device is registered with the authentication server.

[0011] In some embodiments, the second user device is local and directly connected to the OT asset while sending the token to the OT asset and while the OT asset authenticates the user.

[0012] In some embodiments, generating the token is performed in advance to and independent from the OT asset processing the token.

[0013] In some embodiments, the security device is configured to store the token for future authentication.

[0014] In some embodiments, each of the first user device and the second user device provide a user space that is shared among multiple users.

[0015] In some embodiments, the first user device or the second user device or both run a browser, shared by multiple users, in the user space to perform the method.

[0016] In some embodiments, the OT asset operates as a server to serve a website to the browser of the second user device, the website offering authentication to the user.

[0017] In some embodiments, the OT asset is offline from the authentication server while processing the token and authenticating the user device.

[0018] In some embodiments, the method further comprises establishing, independent from the authentication server, a communication channel between the OT asset and the user device upon authenticating the user.

[0019] In some embodiments, stablishing the communication channel comprises calculating a session key based on the public key of the security device. [0020] In some embodiments, the method further comprises calculating the session key using an elliptic curve Diffie-Hellman key exchange protocol using: by the OT asset: the PoP public key of the security device available in the token and the private key of the OT asset; and by the security device: the public key of the OT asset and the private key of the security device forming a key pair with the PoP public key.

[0021] In some embodiments, the method further comprises re-generating the PoP public key by the security device for each request.

[0022] In some embodiments, the PoP public key and associated private key have a key length that is based on a desired security level and token lifetime.

[0023] A method for authenticating a user as performed by an operational technology (OT) asset comprises: receiving a token from a user device that is communicatively coupled to a security device, the token comprising a proof-of-ownership public key and a signature of the token; checking the signature of the token using a public key of an authentication server stored in the OT asset; sending a challenge to the user device; receiving from the user device a signature of the challenge calculated using a private key stored in the security device and forming a key pair with the PoP public key; verifying the signature using the PoP public key of the security device available in the token; and upon verification, authenticating the user with the OT asset.

[0024] A method for authenticating a user with an operation technology (OT) asset as performed by an authentication server comprises: receiving a request for a token from a user device being communicatively coupled to a security device, the request comprising a proof-of-possession (PoP) public key of the security device and a signature of the (PoP) public key calculated by the security device using a private key corresponding to a registration public key of the security device, the registration public key being registered with the authentication server; generating the token comprising the PoP public key of the security device, a signature of the token calculated by the authentication server using a private key of the authentication server; and sending the token and the signature to the user device.

[0025] A method for providing access to an operational technology (OT) asset, the method comprising: receiving a request for access for the OT asset from a user device associated with a user, the request comprising credential data indicative of credentials of the user; validating the request to authenticate the user; upon authenticating the user, identifying an attribute of the user based on the credential data provided in the request; accessing a policy database to retrieve an access policy stored on the policy database; determining whether the user is authorised to access the OT asset by comparing the identified attribute of the user to the retrieved access policy; and upon determining the user is authorised to access the OT asset, providing a communicative connection between the user device and the OT asset by accessing a credential database to retrieve access credentials of the OT asset to establish the communicative connection, the communicative connection being configured to enable the user to access the OT asset.

[0026] In some embodiments, the request comprises a token generated by an authentication server, the token comprising a proof-of-possession (PoP) public key of a security device associated with the user and a signature of the token calculated by the authentication server using a private key of the authentication server.

[0027] A system for providing access to an operational technology (OT) asset, the system comprising: a credential database configured to store access credentials of the OT asset, the access credentials being configured to enable access to the OT asset; a policy database configured to store an access policy of the OT asset; and an access module communicatively coupled to the credential database and the policy database, the access module being configured to: receive a request for access for the OT asset from a user device associated with a user, the request comprising credential data indicative of credentials of the user; validate the request to authenticate the user; upon authenticating the user, identify an attribute of the user based on the credential data provided in the request; access the policy database to retrieve an access policy stored on the policy database; determine whether the user is authorised to access the OT asset by comparing the identified attribute of the user to the retrieved access policy; and upon determining the user is authorised to access the OT asset, providing a communicative connection between the user device and the OT asset by accessing a credential database to retrieve access credentials of the OT asset to establish the communicative connection, the communicative connection being configured to enable the user to access the OT asset.

Brief Description of Drawings

[0028] Figure 1 illustrates one example of authenticating an operator with an OT asset, according to an embodiment.

[0029] Figure 2 illustrates a process for creating a token, according to an embodiment.

[0030] Figure 3 illustrates a method for using the token generated in Figure 2, according to an embodiment. [0031] Figure 4 illustrates a process for creating a token, where the token is encrypted so that only the OT asset can decrypt the token, according to an embodiment.

[0032] Figure 5 illustrates a method for using the token generated in Figure 4, where the token is encrypted so that only the OT asset can decrypt the token, according to an embodiment.

[0033] Figure 6 illustrates a method for authenticating a user as performed by an operational technology (OT) asset, according to an embodiment.

[0034] Figure 7 illustrates a method for generating a token for a user who has already been authenticated by an authentication server, as performed by the authentication server, according to an embodiment.

[0035] Figure 8 illustrates a token according to the present disclosure comprising additional information regarding the privileged access of users.

[0036] Figure 9 illustrates the disclosed privileged access management (PAM) architecture.

[0037] Figure 10 illustrates a method for providing access to an OT asset, according to an embodiment.

Description of Embodiments

[0038] To prevent unauthorised users of OT assets from disrupting operations, it is desirable (as a fundamental approach) to deploy effective authentication mechanisms to enable secure access to ICS networks and their critical assets and applications.

However, a disparity between technological deployments at levels 1 to 3 of an ICS platform (based on the Purdue Model) and an authentication/authorisation server (deployed at the upper levels, i.e., levels 3 and above) can disrupt the authentication service for both assets and services deployed at levels 1 and 2 of the ICS. This is a significant issue for ICSs that comprise remote deployment of level 2 assets and services (HMI, SCADA, OCS servers) and level 1 assets and services (PLCs, RTUs, etc.). In such scenarios, it is likely that authentication and access management for the services and assets operating at levels 1 and 2 are disrupted due to potential network disconnections as authentication in a disconnected network is not practical. Consequently, technicians and system engineers (who need to access to ICS assets at levels 1 and 2) would then not be able to undertake required maintenance routines.

[0039] Figure 1 illustrates one example scenario 100 comprising an OT asset 101 (which is a computer numerical control (CNC) milling machine in this example). The OT asset 101 is controlled by an operator 102 (e.g., a technician) via a machine user device 103, through which operator 102 can change, adjust and monitor machine parameters. Since the access to the control of the machine should only be possible for authorised users, machine user device 103 authenticates operator 102. To this end, there is provided an authentication server 104 with which the operator 102 is registered. The machine user device 103 is connected to the authentication server 104 via a computer network connection 105, such as the internet. In this scenario, the operator 102 can provide user credentials to the machine user device 103, the machine user device 103 can check those credential with authentication server 104 and upon successful validation of the user credentials, machine user device 103 provides access to machine control functions.

[0040] However, since machine user device 103 and OT asset 101 are located at a remote location, it is possible that the computer network connection 105 breaks and no communication is possible between machine user device 103 and authentication server 104. In that case, the operator 102 would not be able to control the machine, which would lead to down time as a result of a computer network failure. To prevent this down time event, operator 102 carries a security device 106 that stores authentication data which, when provided to the machine user device 103, enables the machine user device to authenticate the operator 102 without connecting to the authentication server 104. That authentication data may be in the form of a token and the operator 102 can obtain this authentication data and copy it onto the security device through the use of an authentication user device 107. This authentication user device 107 may be located at a less remote location and may have a more stable connection with the authentication server 104. Further, even if that connection is not more stable, the authentication data can be generated once when the authentication server 104 is reachable, and stored on the security device 106 for later, offline use. The generation and offline use of the token is described below. In yet a further example, the authentication user device 107 and the machine user device 103 are the same device or the same machine. That is, the operator 102 can direct a browser application to the authentication server 104 or to the OT asset 101.

[0041] The security device 106 may be a key fob that can exchange data over universal serial bus (USB), near field communication (NFC) or other technologies. It may be powered by USB or NFC or may comprise an integrated battery. Security device 106 may have hardware security circuits that make it extremely difficult to extract any authentication information without permission. As such, security device 106 can store private keys and token data and may be equipped with a biometric sensor (e.g., fingerprint sensor) that enables it to execute cryptographic command upon user biometric-based approval. The security device 106 may also be able to generate the private keys through an integrated random number generator, and may comprise dedicated circuitry to perform cryptographic operations, so that the private key does not leave the security device 106. The security device 106 may also be integrated into other devices, such as smart phones. For example, Apple’s Secure Enclave or Samsung’s Secure Element may function as the security device 106. In that case, a smart phone or tablet may operate as the authentication user device 107 and the integrated security circuitry operates as the security device 106.

[0042] Authentication user device 107 and machine user device 103 may execute a browser application to display web pages to operator 102 to perform the authentication steps. Those web pages can be served by authentication server 104, that is, the browser contacts the internet protocol (IP) address of the authentication server 104. Further, the web pages can be served by the OT asset 101 to the machine user device 103, that is, the browser running on the machine user device 103 contacts the IP address of the OT asset 101. If the operator’s 102 smart phone or tablet computer is used as the authentication user device 107, the browser application on that smart phone or tablet computer contacts the corresponding IP address. In some examples, the user devices that allow for user interaction to generate and use tokens provide a user space that is shared among multiple users. In this shared user space, the browser application may be used to provide user interaction. The browser application, with all its personal settings and user data is also shared by multiple users. Therefore, it is difficult to authenticate a user based on the credentials (such as shared MS Windows login credentials) provided to either of the user devices because it is difficult to determine which of the multiple users is currently operating the user device. For example, for either device 103/107 there may be a single user account on an MS Windows machine for all users. This distinguishes the OT asset from an IT asset, such as a desktop personal computer or mobile phone. It is not relevant which user is logged into the machine, the server (such as a web server or another type of server) authenticates the user. For example, authentication server 104 authenticates users using a multi-factor authentication (MFA) protocol such as FIDO2 before it generates a token for them.

[0043] This disclosure proposes a unified and secure authentication solution for (low level) devices (such as OT asset 101) that are typically adopted in ICS in disconnected scenarios where a human technician’s ( such as operator 102) engagement with high- level identity access management (IdAM) servers (such as server 104) of the ICS is not possible, and thus can likely disrupt routine or maintenance work in Cis, potentially leading to adverse consequences (both from operations and security perspective).

[0044] The disclosure provides a software token-based multi-factor authentication (MFA) protocol based on the OAuth 2.0 framework. Steps of the disclosed method comprise the following steps:

[0045] Users 102 of an ICS receive proof-of-possession (PoP) software-based tokens from the Identity and Access Management (IdAM) server 104 when they login into the system (during normal situations, i.e., when the IdAM server 104 is available) - these are customized as part of the proposed protocol. [0046] The token associated with each user is stored on its portable security devices/elements (SD/SE) 106, i.e., security keys, to be used during network disruptions, i.e., when the IdAM server 104 is not accessible. In such situations, the users 102 will be able to login into the ICS system components 101 (i.e., assets and services) by presenting their token to these components whilst closely following the steps of execution of the proposed protocol.

[0047] The format of PoP tokens is designed in such a way that the ICS system components 101 can securely validate a token without the need to communicate with a IdAM server 104 (which is now unavailable). Moreover, the security features of the designed tokens do not allow adversaries to manipulate, forge, or replay them. If a token is validated, the OT asset grants access to the owner of the token (the legitimate user), otherwise, access to the service will be denied.

Assumptions/Pre-r equisites:

[0048] The following assumptions are made in some embodiments:

• The technician (user) and IdAM server have already mutually authenticated (using FIDO2 for example) and established the shared session key sKey.

• The public -private key pair of the IdAM server is (PK_Ser, SK_Ser ).

• The public -private key pair of the security device (SD) is (PK_SD, SK_SD). The public key PK_SD has been already registered with the IdAM server through authentication (based on the WebAuthen protocol as part of the FIDO2 protocol). The IdAM server has stored the public key of the security device PK_SD in its database as part of the authentication between the user and the server.

• The remote device (RD) (also referred to as the OT asset 101 herein) can be a controller (e.g., a PEC) or an application deployed on a workstation (e.g., an engineering workstation) that provides access to a controller device (this entity is called a “Resource Server ' in OAuth terminology)

• RD has already registered with the IdAM server and, as part of the registration process, has stored the public key of the server. The public key of the RD (i.e., PK_RD) is stored by the server.

• The public -private key pair of RD is (PK_RD, SK_RD) which is generated using an Elliptic Curve (EC) key generation algorithm, i.e., PK_RD = SK_RD. G, where G is an elliptic-curve point that generates a cyclic group for key generation. G is considered as a system parameter (i.e., all the entities know the value of 6).

• All communication may take place through insecure channels (e.g., public internet). Thus, the exchanged messages can be intercepted and replayed by attackers as the designed protocol is resilient to these attacks.

• One or more of the following claims may be included in a token, such as a Concise Binary Object Representation (CBOR) token (according to RFC 8392 and RFC 7519): issuer (iss), subject (sub), scope(sco), audience (aud), expiry(exp), not before(nZ?/), and CBOR web token identifier (cti). Other claims may also be included. Moreover, the proof of possession key (PoP key) of the technician’s SD is included in the token.

• The required security level (SL) and token lifetime are two input parameters that affect the size of PoP keys. These parameters may be incorporated into the protocol, such as by a user configuration. It is noted that the tokens can be configured to have a relatively short lifetime, such as 1 or 2 days or up to a week. In that case, the security level is relatively high using a standard Rivest- Shamir-Adelman (RSA) key length of 2048-bit for RSA, for example. Therefore, to maintain a recommended security level, it is possible to use shorter keys. This is an advantage when communicating with resource- constrained OT assets. Processing long keys places a significant computational burden on light-weight architectures, such as Internet of Things (loT) component. Therefore, reducing key length by using short-lived tokens can make a significant improvement to response times.

• SD may be equipped with a built-in biometric reader module (e.g., fingerprint reader module). It runs a command only if the technician approves that command (by applying his biometric data, e.g., fingerprint). In other example, simply possession of the SD is sufficient and the SD performs requested operations without biometric approval.

• The clocks of the server and RD are synchronized. This is a relatively loose requirement since a few minutes time difference should be acceptable as long as the expiry of the token can be properly considered.

• In one example, the contents of tokens are not confidential. Thus, tokens are not encrypted (although their integrity is protected using the signature of the server). However, another example of the protocol suite is designed for application scenarios in which the contents of tokens are confidential and must not be readable by any entity other than the IdAM server and RD. It should be noted that the contents of tokens may be encoded using JSON or CBOR. Thus, even if they are not encrypted, a curious (not malicious) technician still needs to decode them to a human-readable format before he is able to read them.

Protocol Design:

[0049] The disclosed protocol consists of two sub-protocols, i.e., Token Generation & Transmission (TGT) (performed by the authentication server) and Token Submission & Validation (TSV) (by the OT asset).

[0050] Figure 2 illustrates a process for creating a token. The operator 102 triggers the process by sending 201 a command (cmd) to the security device 106. This triggering may be through a web browser that has user interaction elements, like buttons, that commence the process in response to the operator 102 activating that button. The browser then calls a routine that sends the command to the security device 106 at step 201. In response, the security device 106 generates a proof-of-ownership (PoP) key pair including a PoP public key (PKp_op) and a corresponding private key (SKpop). This key pair may be an elliptic curve (EC) key pair and may be generated by an EC key generator algorithm, such as PKp_op = SKp_op . G, where G is a system parameter “generator” and represents a point on an elliptic curve.

[0051] The security device 106 also stores a second key pair, which is referred to as a registration key pair including a registration public key and registration private key because the registration public key is registered with the authentication server 104 as being associated with a user that is authorised to control OT asset 101. This is also referred to simply as security device key pair (PKSD, SKSD). It is noted that the registration key pair remains the same for all tokens being generated but the PoP key pair is re-generated each time a token is requested. The security device 106 calculates a signature of the PoP public key using the registration private key and sends 202 the generated PoP public key with the signature back to the authentication user device 107.

[0052] Authentication user device 107 receives the response from the security device 106 and includes the response (the PoP public key and signature) together with request data into a message. Authentication user device 107 encrypts the message using a shared session key and sends 203 the encrypted message to the authentication server 104. The authentication server 104 decrypts the message using the shared session key to obtain the request data, the PoP public key and the signature. Since the security device has been previously registered with the authentication server 104, the authentication server 104 stores the registration public key that forms a key pair with the registration private key stored on the security device 106. If the registration public key is not stored as an authorised key, authentication server 104 does not issue the token. In other words, generating the token is conditional on determining that the registration public key of the security device 106 is registered with the authentication server 104. [0053] Authentication server 104 can check the signature on the PoP public key using the registration public key (PKSD) stored in/registered with authentication server 104. If the signature is valid, the authentication server 104 can conclude that the PoP public key has been generated by a security device that is registered with the authentication server 104.

[0054] In response to determining that the signature is valid, authentication server 104 checks the access rights of the operator 102 associated with the security device 106 (i.e. associated with public key PKSD). This ensures that the request data in the message mi is legitimate. If it is legitimate (and the signature is valid), authentication server 104 generates a token TK. The token includes fields for issuer, subject, scope, audience, expiry, not-before, and identifier. The authentication server 104 combines (i.e. concatenates) the token, with a signature of the token using the server private key and with the public key of the OT asset 101 and encrypts the result with the shared session key. The authentication server 104 then sends the encrypted result as message m2 to the authentication user device 107.

[0055] Authentication user device 107 can now decrypt the message m2 using the shared session key and obtain the token. Authentication user device 107 then checks the server signature on the token using the server public key to verify that the token has in fact been generated by the authentication server 104 and not an attacker.

Authentication user device 107 can also store the token on security device 106. As a result, operator 102 can now disconnect the security device 106 from the authentication user device 107 and keep possession of the token by way of keeping possession of the security device 106. This way the token is only stored on the security device 106, which has a secure hardware circuit. Therefore, it is very difficult for an attacker to steal the token from the operator 102. This means the generation of the token is performed in advance to and independent from the OT asset 101 processing the token as explained below with reference to Figure 3. Further, the token is stored on security device 106 because the user can carry the security device 106 with him/herself (always has access to the token and can use it), whereas if the token is stored on 107, the user will be limited to carry 107 everywhere. It is noted, that even with possession of the token itself, without access to the security device 106, it is not possible to gain authentication as explained later.

[0056] Figure 3 illustrates a method for using the token generated in Figure 2 to authenticate operator 102 with OT asset 101. Operator 102 connects the security device 106 with the machine user device 103 (via USB, NFC, etc.), which, in turn, is local and directly located to the OT asset 101 while sending the token and authenticating the operator 102. This means the machine user device 103 and the OT asset 101 are in the same local network and can communicate with each other even if network access to other remote servers, such as authentication server 104 has been disrupted. It is noted that from here, the method does not require a network connection to the authentication server 104. That is, the OT asset 101 is offline from the authentication server 104 while processing the token and authenticating operator 102. The machine user device 103, as directed by the operator 102 interacting with a browser application, for example, obtains the token and the signature generated by the authentication server 104 and stored on the security device 106 (potentially involving biometric authentication of the operator 102 with the security device 106). Machine user device 103 obtains the token and the server signature from security device 106 and creates a message including the token and the server signature of the token. Machine user device 103 sends 301 the message together with a random number r to the OT asset 101.

[0057] The OT asset 101 checks the audience field in the token to ensure the token has been generated for the OT asset 101 by checking that the identifier of the OT asset 101 is in the audience field of the token. If that is the case, OT asset 101 checks the signature on the token using the server public key (PKser). This way, the OT asset 101 confirms that the token has in fact been generated by authentication server 104 and not by an attacker. In response to the signature being valid, OT asset 101 calculates a signature on the random number (generated by the machine user device 103) using a secret key stored on the OT asset 101. This secret key is denoted as SKRD , where “RD” stands for remote device, which is used herein synonymously with OT asset 101. The OT asset 101 then creates a message n including a further random number r’ generated by the OT asset 101 and the signature on the random number r using the secret key of the OT asset 101. The OT asset 101 then sends 302 the message to machine user device 103.

[0058] Machine user device 103 checks the signature on the random number r using the RD public key that forms a key pair with the private key SKRD stored on the OT asset 101. If the signature is valid, machine user device 103 has confirmed that the response has actually been created by the OT asset 101 and not another man-in-the middle fishing for a response. In response to validating the signature, machine user device 103 sends 303 a command to the security device 106 to calculate a signature on the random number r’ generated by the OT asset 101 using the PoP secret key. The security device 106 returns 304 the signature and machine user device 103 sends 305 the signature back to OT asset 101. OT asset 101 now has the PoP public key from the token (which has been signed by the authentication server 104) and can use that PoP public key from the token to verify the signature on r’ generated by the PoP secret key in the security device 106. If the signature is valid, the OT asset 101 has confirmed that the security device 106 is the same device for which the authentication server 104 has issued the token and not the security device of an attacker. This way, an attacker would not be able to change the public key in the token to be able to impersonate the operator 102 and would not be able to generate the correct signature on r’ .

[0059] Both sides, that is the OT asset 101 and the machine user device 103 can now use the available data to generate a shared session key. More particularly, both sides can perform an elliptic curve Diffie-Helman (ECDH) operation to generate a symmetric key that can be used for both encryption and decryption. This means the OT asset 101 multiplies the PoP public key PKp_op available from the token with its own secret key SKSD. Noting that PKp_op = SKp_op.G the result is sessionKey=SKp_op.G.SKRD. Similarly, the machine user device sends 306 a command to the security device to multiply the RD public key of the OT asset 101 PKRD (available from the message received from authentication server 104 at step 204) with its own PoP private key SKp_op stored on security device 106. Noting that PKRD=SKRD.G SO the result is sessionKey=SKRD.G.SKp_op which is identical to the session key calculated by the OT asset 101 because elliptic curve multiplication is commutative. This establishes, independent from the authentication server, a communication channel between the OT asset 101 and the machine user device 103 upon authenticating the user device. The security device 106 returns 307 the session key or stores the session key securely to perform operations using the session key on the security device 106.

[0060] Once the session key is generated and available to the OT asset 101 and the machine user device 103, this means the user is authenticated because with the session key, the operator 102 can issue commands to the OT asset 101 and the commands are encrypted with the session key. It is noted that the session key is only valid until the expiry of the token as indicated at the exp field of the token. That is, OT asset 101 checks for each communication whether the token has expired. Once the token is expired, operator 102 needs to obtain a new token for which a new PoP key pair is generated so that the session key is different for each token.

[0061] It is further noted that the session key is relatively short because elliptic curve keys are shorter than keys relying on prime factorisation. Further, the expiry date in the token means an attacker only has a limited amount of time available to crack the key by brute force, for example. Therefore, the keys can be even shorter while still maintaining a relatively high security level. As an advantage, the short keys can be used by computing nodes with relatively low computing power, such as loT or embedded devices.

[0062] Figure 4 illustrates another example of generating the token. The difference to the method in Figure 2 is that the authentication server 104 encrypts the token using the PKRD public key of the OT asset 101 for sending 404 it to the authentication user device 107. This way, the authentication user device 107 can decrypt the message but can still not decrypt the token. As a result, the operator 102 is not able to check what the token includes. For example, the token may include fields that actually do not authorise the operator 102. However, the operator would only find out when the operator 102 attempts to authenticate with the OT asset 101. [0063] Figure 5 illustrates the use of the generated encrypted token. More particularly, machine user device 103 obtains the encrypted token from security device 106 and sends 501 the encrypted token with the server signature to the OT asset 101. Now the OT asset can use its own secret key SKRD to decrypt the token and send back 502 a random number r and the PoP public key. When the machine user device 103 receives the PoP public key, it compares the received PoP public key with the stored PoP public key. If they match, machine user device 103 has authenticated the OT asset 101 because the PoP public key proves that the OT asset 101 has access to the secret key required to decrypt the token. Therefore, it is not necessary to send a random number from the machine user device 103 to the OT asset 101 for calculating a signature is in Figure 3. This further reduces computational overhead and increases security.

[0064] Figure 6 illustrates a method 600 for authenticating a user as performed by OT asset 101. The method steps correspond to the steps of the OT asset shown in Figure 3 and 5. Method 600 commences by the OT asset 101 receiving 601 a token from machine user device 103 that is communicatively coupled to security device 106 as described above. The token comprises the PoP public key and a signature of the token generated using the private key of the authorisation server 104. OT asset 101 checks 602 the signature of the token using the public key of authentication server 104 stored in the OT asset 101 from previous registration of the OT asset with the authentication server 104. OT asset 101 then sends a challenge r to the machine user device 103. In response, OT asset 101 receives from the machine user device 103 a signature of the challenge r calculated using a private key stored in the security device 106 and forming a key pair with the PoP public key. OT asset 101 has access to the PoP public key in the token together with a signature from the authentication server 104 on the PoP public key to ensure its authenticity. Therefore, OT asset 101 can now verify 605 the signature using the PoP public key of the security device in the token. Finally, upon verification, OT asset 101 authenticates 606 the user, such as by establishing a secure communication channel using an ECDH protocol, for example. [0065] Figure 7 illustrates a method 700 for authenticating a user with OT asset 101 as performed by authentication server 104. Essentially, the authentication server 104 generates the token in this method. That is, the authentication server 104 receives 701 a request for a token from registration user device 107 that is communicatively coupled to security device 103 as described above. The request comprises the PoP public key of the security device and a signature of the PoP public key calculated by the security device using a private key corresponding to a registration public key of the security device. The registration public key is registered with the authentication server which means that the authentication server 104 has stored the registration public key in a list of users that are registered with rights to operate OT asset 101. Authentication server 104 then generates 702 the token comprising the PoP public key of the security device. Authentication server 104 further calculates a signature of the token using a private key of the authentication server. It is noted that the corresponding server public key is available to the OT asset 101 locally. Finally, authentication server sends 703 the token and the signature to the registration user device 107, which may store the token on security device 106 for later use with the machine user device 103 according to method 600 in Figure 6.

PAM architecture

[0066] A privileged access management (PAM) architecture according to the present disclosed will now be discussed. The PAM architecture may be used to manage, control, and secure access to privileged accounts and sensitive information within an organization. In the following, the functions and capabilities of the disclosed PAM architecture are listed. Then, the technical details about the architecture of the disclosed PAM architecture are presented. In essence, the disclosed PAM architecture provides a method for managing access privileges for both privileged and non-privileged users, to ICS/OT assets in islanded and non-islanded modes of operation (including highly distributed and/or remote infrastructures). An islanded mode may be a state in which an OT network or system operates independently and is isolated from external networks, including other parts of the organization's IT infrastructure and public networks. [0067] Functions of the PAM architecture

[0068] The disclosed PAM architecture may provide several capabilities that enable a system to securely manage, and control access to privileged accounts within an organization. These capabilities may be based on several functions that are discussed in the following:

• Credential Management: One of the functions of the disclosed PAM architecture may be to securely store and manage privileged account credentials in a centralized vault. This way, the admin credentials of hardware/software systems (e.g., PLCs, servers, Firewalls, etc.) may be protected from unauthorized access. Moreover, the regular change of passwords for privileged accounts may be automated to enhance security.

• Access Control: The disclosed PAM architecture may grant temporary, timelimited access to privileged accounts only when necessary. This may significantly reduce the risk of prolonged exposure (“Just-in-Time” Access). This access control may also be configured such that it enforces the principle of least privilege by providing users with the minimum level of access needed to perform their tasks.

• Strong Authentication and Authorization: The disclosed PAM architecture may be based on the disclosed method for authenticating a user with an operational technology (OT) asset. In other words, the disclosed PAM architecture may be based on the MFA authentication described herein. Utilising the disclosed method for authenticating a user with an operational technology (OT) asset within the PAM architecture can enhance the security of privileged access by requiring multiple forms and steps of verification. Moreover, using tokens as described in this disclosure, the PAM architecture may assign access permissions based on job responsibilities, ensuring users have appropriate privileges (i.e., Role-Based Access Control). However, in some embodiments, the disclosed PAM architecture may not utilise the disclosed method described herein. More specifically, the disclosed PAM architecture is not limited to a security device (e.g., security device 106 of Figure 1) carrying a token for enabling authentication, as discussed in this disclosure. The disclosed PAM architecture may utilise a different token-based authentication process, utilise a token-less authentication processes (such as one-time passcodes) or other authentication processes (such as session-based authentication) and achieve the same outcome.

• Policy Enforcement: The PAM architecture may enable organizations to define and enforce access policies consistently across the enterprise (policy management).

• Integration with IdAM: One feature of the designed PAM architecture is that it may be integrated with existing identity and access management (IdAM) platforms to synchronize user identities and access permissions, such as a IdAM platform that utilises authentication server 104 as discussed in this disclosure, for example. The PAM architecture may also provide Single Sign-On (SSO) feature to enhance user experience by enabling users to access multiple systems with a single set of credentials.

[0069] As discussed above, the above-mentioned functions and capabilities may be provided based on the usage of tokens of the disclosed method. More specifically, the above-mentioned functions and capabilities may be provided on the Token Generation and Storage (TGS) and Token Submission and Validation (TSV) sub-protocols, as discussed in this disclosure. However, it is noted that the capabilities of the PAM architecture may be provided by other protocols. Any other authentication protocol may be used. For example, the capabilities of the PAM architecture may be utilised by a different token-based authentication process, a token-less authentication processes (such as one-time passcodes) or other authentication processes (such as session-based authentication) and achieve the same outcome.

[0070] Methodology

[0071] As previously discussed, the disclosure PAM architecture may be based on PoP tokens generated by the IdAM server 104 (with reference to Figure 1) and stored on the users’ security keys (such as security device 106). However, additional information may be incorporated in the PoP tokens issued for users with privileged access (i.e., admin users). This information may be generated based on the access rights assigned to each admin user regarding their privilege access to hardware/software systems deployed within the network (e.g., PLCs, HMIs, Servers, etc.). If the disclosed PAM architecture utilises other authentication protocol, such as other token-based protocols, the request for authentication (or tokens) may also have additional information as discussed.

[0072] As such, user groups may be created based on the roles available across the network, e.g., PLC Administrators, PLC Operators, SCADA Operators, Backup Operators, Guests, etc. Each group may be assigned a unique id number (Group ID). Preferably, all the users with privileged access are a member of at least one of these groups. The Group ID may be explicitly expressed in their respective tokens by incorporating the id of group(s) in which the users are a member. In addition, to support privileged access to files, an Owner ID attribute may be incorporate into tokens which may indicate what files and folders a user owns.

[0073] Figure 8 illustrates token 800 according to the present disclosure comprising additional information regarding the privileged access of users. In other words, Figure 8 shows the token format for users with privileged access according to the present disclosure. In particular, token 800 comprises attributes 801 related to the additional information regarding the privileged access of users. Attributes 801 may be considered to be PAM attributes or PAM-specific attributes. In the example shown in Figure 8, attributes 801 comprise a username, Group ID and Owner ID of the user with privileged access. Token 800 also comprises fields 802, which may be token attributes described earlier in this disclosure. For example, fields 802 may be a PoP public key of security device 106, a corresponding signature, or another cryptographic key and/or corresponding signature.

[0074] In some examples, there may be privileged accounts for every hardware/software component/device across the network (e.g., PECs, HMIs, Firewalls, etc.). These may be accounts that a component/device (i.e., an OT asset) recognizes as privileged accounts that are allowed to access its resources. For some systems/devices developed by third party vendors, the access management method adopted by the vendor may not be able to be modified. So, to address this in the disclosed PAM architecture, these systems/devices may be considered as “black box” packages. In this regard, a list of privileged accounts may be prepared which considers all the system/devices deployed within the network. The credentials of these accounts may be securely stored in a credential repository (a secure vault) such that they are only accessible by the PAM system, i.e., users cannot access them. This is the essence of the disclosed PAM architecture, which will now be described in more detail.

[0075 ] The propo sed architecture

[0076] The technical details of the PAM architecture are now discussed. During the development of the disclosed PAM architecture, the following were assumed: the ICS network consists of packages of Siemens products (S7 PLCs, SIMATIC Manager system, WinCC Engineering Workstation, TIA Portal, etc.), Allen Bradley systems (ControlLogix PLCs, FactoryTalk systems, etc.), and OPC UA system (server and client). However, it is noted that the disclosed PAM architecture is not limited to these assumptions or the use of the above-mentioned systems.

[0077] Figure 9 illustrates the disclosed PAM architecture 900. In other words, Figure 9 illustrates an example system for providing access to an OT asset. As Figure 9 shows, the disclosure PAM architecture may consist of three components: (1) access module 911, (2) credential database 912, and (3) policy database 913. Access module 911 may also be referred to as Access Management Agent, for example. Credential database 912 may also be referred to as Credential Repository, for example. Policy database 913 may also be referred to as Policy Store, for example. Access module 911, credential database 912 and policy database 913 may be referred to collectively as access management engine 910.

[0078] In some examples, the access management engine 910 may be registered with the authentication server 904. In some examples, the access management engine 910 is local and directly connected to the OT asset. Further, the connection between access management engine 910 (more specifically, the access module 911) and OT asset is preferably secure. The connection between access management engine 910 and OT asset may be over a network interface card that interfaces the OT asset to Level 0 or 1 asset, for example.

[0079] PAM architecture 900 may also comprise a user admin 902 and an authentication server 904. Authentication server 904 may be a similar or the same server described with reference to Figure 1 (e.g., authentication server 104). As such, authentication server 904 may also be referred to as a IdAM server. PAM architecture 900 may further comprise one or more OT assets (not shown).

[0080] Access module 911 may be a software module configured to perform authentication, authorization, and monitoring of user access to assets within an ICS/OT environment. In other words, access module 911 may be a software -based package configured to manage users request to access the systems/devices with privileged accounts. Thus, every connection to the systems/devices may go through the access module 911. Depending on the network configuration, there may be one or more modules at different levels of the ICS network. However, in the example embodiment shown in Figure 9, only one module is shown for simplicity. Preferably, access module 911 is deployed at level 2 or level 1 depending on the availability of systems/devices (i.e., OT assets) at each level.

[0081] Access module 911 may be configured to run TSV sub-protocol to thereby authenticate users and validate their tokens. Once a user is successfully authenticated by the access module 911 and their token is validated, a connection to the desired system/device may established by the access module 911 between a user device and the system/device, where the connection is established by logging into the system/device using the stored privileged credentials. The connection may then be securely transferred to the user who can start working with the desired system/device (e.g., an OT asset). Additionally or alternatively, access module 911 may be configured to perform any other authentication protocol to authenticate users. [0082] Access module 911 may be deployed in a computing device at the OT site in the proximity of the OT asset to which administrative access may be needed, in such a way that all communication to the OT asset must be transmitted through the softwarebased agent. In other words, there may be no physical connection to the OT asset except the one that connects it to the access management agent. Access module 911 may be implemented as a computing component such as a computer processor, for example. Access module 911 may also be implemented as part of a server, for example.

[0083] Credential database 912 may be a secure vault. More specifically, credential database 912 may be a storage of the OT asset’s credentials comprising usernames and passwords or cryptographic keys and may serve as a secure vault and may be utilised by the access management agent, to obtain the credentials required for logging into the ICS/OT asset. In essence, access module 911 may be configured to communicate with credential database 912. For example, access module 911 may be configured to access credential database 912 and/or retrieve or store data.

[0084] Credential database 912 may be deployed next to, near or remotely from access module 911. Credential database 912 may also be integrated into the access module 911 (depending on the implementation). Preferably, credential database 912 is deployed at the control layer as described in ICS/OT reference architectures such as the Purdue Enterprise Reference Architecture (PERA). Credential database 912 may securely store the privileged credentials of the systems/device that are deployed across the network. More specifically, credentials of the OT asset’s (usernames and passwords or cryptographic keys) may be stored in the credential database 912 by the primary system administrator and/or security administrator, i.e., the credentials are not shared between other administrators or maintenance users (e.g., technicians) who need to access the OT asset.

[0085] An automated password change mechanism may be implemented that regularly changes the passwords of privileged accounts on systems/devices registered with the access module 911. This significantly improves the security of the system. Similar to the OT asset (for example, OT asset 101 of Figure 1), credential database 912 may have a connection to the local software -based access management agent only and it just replies to API calls issued by the local software -based access management (i.e., the communication between the access module 911 and credential database 912, may be protected by a service account that enables API authorization).

[0086] Policy database 913 may store the OT asset access control rules (for example, access control information for users and groups of users). In other words, policy database 913 may securely store network access policies defined by network security administration team on the IdAM server 904. These policies may determine the access rights of each group ID for every system/device registered with the access module 911. It may be assumed that these policies are first defined on the IdAM server 904 and then may be securely uploaded to the policy store either manually by the security administration team or automatically by the IdAM server 904.

[0087] Similar to the credential database 912, access module 911 may be configured to communicate with policy database 913. For example, access module 911 may be configured to access policy database 913 and/or retrieve or store data. In some examples, policy database 913 may have an established connection to the access module 911 only and it replies to API calls issued by the access module 911 (i.e., it is protected by a service account that enables API authorization). The policy database 913 of local software-based access management may be constantly synchronised with the central PS module typically deployed at the operations and control layer as described in ICS/OT reference architectures such as the Purdue Enterprise Reference Architecture (PERA).

[0088] Method for accessing an OT asset

[0089] Figure 10 illustrates a method for providing access to an OT asset. With reference to Figure 9, access module 911 receives 1001 a request for access for the OT asset from a user device associated with a user. The request comprises credential data indicative of credentials of the user. The credential data may comprise one or more cryptographic keys or other data indicative of the user’s credentials, such as passkeys or the like, or other information that identifies the user or the credentials of the user (such as the employee position, or the like). In one example, the request may comprise the PoP token according to the present disclosure. In some examples, the token may provide additional information such as attributes 801 of Figure 8.

[0090] As previously discussed, in some embodiments, the request may comprise a token according to the disclosed method. In other words, the request may comprise a token generated by an authentication server, the token comprising a proof-of- possession (PoP) public key of a security device associated with the user and a signature of the token calculated by the authentication server using a private key of the authentication server. However, as previously discussed, the disclosed PAM architecture may not be based on the token-based authentication described herein. The disclosed PAM architecture may be based on any other authentication protocol and hence, the request may be based on the utilised authentication protocol.

[0091] Access module 911 then validates 1002 the request to authenticate the user. If the user is a privileged user (e.g., a user with privileged access), then access module 911 will successfully validate the user. Access module 911 may validate the user using the disclosed method for authenticating a user. For example, access module 911 may run a TSV sub-protocol, or the like, to validate users’ request. However, access module 911 may validate the user based on other authentication methods, such as token-less authentication processes (such as one-time passcodes) or other authentication processes (such as session-based). Access module 911 may validate the user based on other cryptography methods. Access module 911 may validate the user based on the credential data in the request.

[0092] Upon authenticating the user, access module 911 may identify 1003 an attribute of the user based on the credential data provided in the request. For example, if the request comprises the token shown in Figure 8, then the attribute identified by access module 911 may correspond to the attributes 801 of Figure 8. In other words, the PAM-related attributes available in the tokens (e.g., attributes 801 shown in Figure 8) may enable the PAM system to identify the group membership and file ownership of a user.

[0093] Access module 911 then accesses 1004 the policy database 913 to retrieve an access policy stored on the policy database 913. In other words, access module 911 may then access a policy store (managed by the IdAM server 904, for example) to see what are the access rights of the users that are a member of a particular group. As such, access module 911 determines 1005 whether the user is authorised to access the OT asset by comparing the identified attribute of the user to the retrieved access policy. For example, the access policy may indicate that only members of a certain group are authorised to access the particular OT asset associated with the request. Therefore, access module 911 may determine 1005 that the user is authorised to access the particular OT asset if access module 911 determines that the user belongs to the authorised group as indicated in the user’s credential data.

[0094] Finally, upon determining the user is authorised to access the OT asset, access module 911 provides 1006 a communicative connection between the user device and the OT asset by accessing a credential database to retrieve access credentials of the OT asset to establish the communicative connection, the communicative connection being configured to enable the user to access the OT asset. In other words, if the identified access rights of a user permit, access module 911 may establish a secure connection to the system/device (based on the user’s request) and logs into the system/device using the credentials stored in the credential repository.

[0095] The connection may be securely transferred (shared) to the user’s device such that the user can start working with the system/device. Therefore, this demonstrates that the additional information in the tokens according to the present disclosure may be integrated into systems/devices developed by third party vendors where access management of these systems/devices may not be modified, for example.

[0096] Advantages [0097] The disclosed PAM architecture brings several advantages for ICS networks deployed within critical infrastructure. Firstly, the disclosed PAM architecture does not need admin users (e.g., users with privileged access) to have any knowledge of the privileged credentials of systems/devices. Instead, these credentials may be stored in a secure vault (i.e., credential repository). This significantly improves the security of the system as the privileged credentials are not shared among a group of administrators (i.e., human users).

[0098] Secondly, the admin users may connect to the systems/devices through the access module 911 and using their own id and credentials instead of privileged credentials. This enables the system to log their individual connection activity in the system based on their id which bring accountability, audit, and non-repudiation security features.

[0099] The third advantage is that the access module 911 changes the privileged credentials regularly without needing users’ cooperation. Moreover, using the disclosed PAM architecture, admin users do not need to receive the updated privileged credentials as they use their own id and credentials to log in. Furthermore, the disclosed PAM architecture provides scalability in terms of the number of admin users. This is because the admin users do not use the privileged credentials to log in.

Summary

[0100] Overall, this disclosure provides a method for authenticating a user with an OT asset that can be performed without connection to an authentication server. At the same time, the authentication server is the central authority for identity management and user access management and exercises that authority by issuing time-limited tokens to users that are in possession of a registered security device.

[0101] It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A method for authenticating a user with an operational technology (OT) asset, the method comprising: an authentication server generating a token by: receiving a request for the token from a first user device being communicatively coupled to a security device, the request comprising a proof-of- possession (PoP) public key of the security device and a signature of the (PoP) public key calculated by the security device using a private key corresponding to a registration public key of the security device, the registration public key being registered with the authentication server; and generating the token comprising the PoP public key of the security device and a signature of the token calculated by the authentication server using a private key of the authentication server; the OT asset processing the token to authenticate the user by: receiving the token from a second user device being communicatively coupled to a security device; checking the signature of the token using the public key of the authentication server stored in the OT asset; sending a challenge to the second user device; receiving from the second user device a signature of the challenge calculated using the PoP private key stored in the security device and forming a key pair with the PoP public key; verifying the signature using the PoP public key of the security device in the token; and upon verification, authenticating the user with the OT asset.

2. The method of claim 1, wherein generating the token is conditional on determining that the registration public key of the security device is registered with the authentication server.

3. The method of claim 1 or 2, wherein the second user device is local and directly connected to the OT asset while sending the token to the OT asset and while the OT asset authenticates the user.

4. The method of any one of the preceding claims, wherein generating the token is performed in advance to and independent from the OT asset processing the token.

5. The method of claim 4, wherein the security device is configured to store the token for future authentication.

6. The method of any one of the preceding claims, wherein each of the first user device and the second user device provide a user space that is shared among multiple users.

7. The method of claim 6, wherein the first user device or the second user device or both run a browser, shared by multiple users, in the user space to perform the method.

8. The method of claim 7, wherein the OT asset operates as a server to serve a website to the browser of the second user device, the website offering authentication to the user.

9. The method of any one of the preceding claims, wherein the OT asset is offline from the authentication server while processing the token and authenticating the user device.

10. The method of any one of the preceding claims, wherein the method further comprises establishing, independent from the authentication server, a communication channel between the OT asset and the user device upon authenticating the user.

11. The method of claim 10, wherein establishing the communication channel comprises calculating a session key based on the public key of the security device.

12. The method of claim 11, wherein the method further comprises calculating the session key using an elliptic curve Diffie-Hellman key exchange protocol using: by the OT asset: the PoP public key of the security device available in the token and the private key of the OT asset; and by the security device: the public key of the OT asset and the private key of the security device forming a key pair with the PoP public key.

13. The method of any one of the preceding claims, wherein the method further comprises re-generating the PoP public key by the security device for each request.

14. The method of any one of the preceding claims, wherein the PoP public key and associated private key have a key length that is based on a desired security level and token lifetime.

15. A method for authenticating a user as performed by an operational technology (OT) asset, the method comprising: receiving a token from a user device that is communicatively coupled to a security device, the token comprising a proof-of-ownership public key and a signature of the token; checking the signature of the token using a public key of an authentication server stored in the OT asset; sending a challenge to the user device; receiving from the user device a signature of the challenge calculated using a private key stored in the security device and forming a key pair with the PoP public key; verifying the signature using the PoP public key of the security device available in the token; and upon verification, authenticating the user with the OT asset.

16. A method for authenticating a user with an operation technology (OT) asset as performed by an authentication server, the method comprising: receiving a request for a token from a user device being communicatively coupled to a security device, the request comprising a proof-of-possession (PoP) public key of the security device and a signature of the (PoP) public key calculated by the security device using a private key corresponding to a registration public key of the security device, the registration public key being registered with the authentication server; generating the token comprising the PoP public key of the security device, a signature of the token calculated by the authentication server using a private key of the authentication server; and sending the token and the signature to the user device.

17. A method for providing access to an operational technology (OT) asset, the method comprising: receiving a request for access for the OT asset from a user device associated with a user, the request comprising credential data indicative of credentials of the user; validating the request to authenticate the user; upon authenticating the user, identifying an attribute of the user based on the credential data provided in the request; accessing a policy database to retrieve an access policy stored on the policy database; determining whether the user is authorised to access the OT asset by comparing the identified attribute of the user to the retrieved access policy; and upon determining the user is authorised to access the OT asset, providing a communicative connection between the user device and the OT asset by accessing a credential database to retrieve access credentials of the OT asset to establish the communicative connection, the communicative connection being configured to enable the user to access the OT asset.

18. The method of claim 17, wherein the request comprises a token generated by an authentication server, the token comprising a proof-of-possession (PoP) public key of a security device associated with the user and a signature of the token calculated by the authentication server using a private key of the authentication server.

19. A system for providing access to an operational technology (OT) asset, the system comprising: a credential database configured to store access credentials of the OT asset, the access credentials being configured to enable access to the OT asset; a policy database configured to store an access policy of the OT asset; and an access module communicatively coupled to the credential database and the policy database, the access module being configured to: receive a request for access for the OT asset from a user device associated with a user, the request comprising credential data indicative of credentials of the user; validate the request to authenticate the user; upon authenticating the user, identify an attribute of the user based on the credential data provided in the request; access the policy database to retrieve an access policy stored on the policy database; determine whether the user is authorised to access the OT asset by comparing the identified attribute of the user to the retrieved access policy; and upon determining the user is authorised to access the OT asset, providing a communicative connection between the user device and the OT asset by accessing a credential database to retrieve access credentials of the OT asset to establish the communicative connection, the communicative connection being configured to enable the user to access the OT asset.