WO2020157369A1

WO2020157369A1 - Remote blockchain network agent for verifying and accepting patch requests from a patch initiator and method thereof

Info

Publication number: WO2020157369A1
Application number: PCT/FI2019/050067
Authority: WO
Inventors: Matteo Pontecorvi; Jan Kok; Ian Oliver; Matteo Signorini
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2019-01-30
Filing date: 2019-01-30
Publication date: 2020-08-06

Abstract

Various embodiments relate to a method for accepting and verifying a patch request to patch a network element from a patch initiator using a remote agent, the method including: receiving, by the remote agent, a request from a blockchain network to check the patch status of the network element; sending, by the remote agent, a patch status request to the network element; receiving, by the remote agent, the patch status from the network element; and transmitting, by the remote agent, the patch status of the network element to the blockchain element.

Description

REMOTE BLOCKCHAIN NETWORK AGENT FOR VERIFYING AND ACCEPTING PATCH REQUESTS FROM A PATCH INITIATOR AND METHOD THEREOF

TECHNICAL FIELD

[0001] This disclosure relates generally to a remote blockchain network agent, and more specifically, but not exclusively, to a remote blockchain network agent that verifies and accepts patch requests from a patch initiator (“PI”).

BACKGROUND

[0002] Currently, network devices use certification authorities to verify patch integrity, however, there are no other remote agents that use a blockchain-based solution to validate the integrity of a network element after a new patch (or a set of new patches and software updates or upgrades) has been applied to the network element.

SUMMARY

[0003] A brief summary of various example embodiments is presented. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various example embodiments, but not to limit the scope of the invention.

[0004] Detailed descriptions of example embodiments adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in later sections.

[0005] Various embodiments relate to a method for accepting and verifying a patch request to patch a network element from a patch initiator using a remote agent, the method including: receiving, by the remote agent, a request from a blockchain network to check the patch status of the network element; sending, by the remote agent, a patch status request to the network element; receiving, by the remote agent, the patch status from the network element; and transmitting, by the remote agent, the patch status of the network element to the blockchain element.

[0006] Various embodiments are described, wherein the patch status is received from a secure storage in the network element.

[0007] Various embodiments are described, wherein the remote agent sends the patch status request after a time window T.

[0008] Various embodiments are described, wherein the blockchain network sends the time window T to the patch initiator.

[0009] Various embodiments are described, further including patching the network element by the patch initiator in the time window T.

[0010] Various embodiments are described, wherein the patch status is a hash.

[0011] Various embodiments are described, further including: sending, by the patch initiator, a patch request to the blockchain network including patch dependencies.

[0012] Various embodiments are described, further including: validating, by the blockchain network, the patch request; and sending, by the blockchain network, to the patch initiator a list of possible configurations of a hardware security module in the network element based upon the patch request.

[0013] Various embodiments are described, further including: sending, by the patch initiator, to the network element a payload including the list of possible configurations, a patch for the network element, and a set of commands to write the result of the patching process to the hardware security module.

[0014] Various embodiments are described, wherein, the BN verifies that the network element has been patched within a time window T specified by the blockchain network. [0015] Various embodiments are described, wherein remote agent resides in the blockchain network.

[0016] Various embodiments are described, wherein, the remote agent resides in a network device separate from the network element.

[0017] Further various embodiments relate to a non-transitory machine-readable storage medium encoded with instructions for accepting and verifying a patch request to patch a network element from a patch initiator using a remote agent, including: instructions for receiving, by the remote agent, a request from a blockchain network to check the patch status of the network element; instructions for sending, by the remote agent, a patch status request to the network element; instructions for receiving, by the remote agent, the patch status from the network element; and instructions for transmitting, by the remote agent, the patch status of the network element to the blockchain element.

[0018] Various embodiments are described, wherein the patch status is received from a secure storage in the network element.

[0019] Various embodiments are described, wherein the remote agent sends the patch status request after a time window T.

[0020] Various embodiments are described, wherein the blockchain network sends the time window T to the patch initiator.

[0021] Various embodiments are described, further including patching the network element by the patch initiator in the time window T.

[0022] Further various embodiments relate to a remote agent device for use in accepting and verifying a patch request to patch a network element from a patch initiator, including: memory; and a processor connected to the memory, the processor configured to: receive a request from a blockchain network to check the patch status of the network element; send a patch status request to the network element; receive the patch status from the network element; and transmit the patch status of the network element to the blockchain element.

[0023] Various embodiments are described, wherein the patch status is received from a secure storage in the network element.

[0024] Various embodiments are described, wherein the remote agent sends the patch status request after a time window T.

[0025] Various embodiments are described, wherein the blockchain network sends the time window T to the patch initiator.

[0026] Various embodiments are described, wherein the remote agent device resides in the blockchain network.

[0027] Various embodiments are described, wherein the remote agent device resides in an auxiliary device separate from the network element.

BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate example embodiments of concepts found in the claims and explain various principles and advantages of those embodiments.

[0029] These and other more detailed and specific features are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which:

[0030] FIG. 1 illustrates a network using BN to verify patches to a network element; [0031] FIG. 2 illustrates a more detailed architecture of the BN solution, in which the remote agent is placed in the architecture as a separate device and interacts with both the BN and the NE via messages; and

[0032] FIG. 3 illustrates the message flow using the remote agent.

DETAILED DESCRIPTION

[0033] It should be understood that the figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the figures to indicate the same or similar parts.

[0034] The descriptions and drawings illustrate the principles of various example embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples recited herein are principally intended expressly to be for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Additionally, the term,“or,” as used herein, refers to a non-exclusive or (i.e., and/ or), unless otherwise indicated (e.g.,“or else” or“or in the alternative”). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. Descriptors such as“first,”“second,”“third,” etc., are not meant to limit the order of elements discussed, are used to distinguish one element from the next, and are generally interchangeable.

[0035] The current embodiment is directed towards how a blockchain network (BN) communicates with and executes commands/ tasks at network elements in order to maintain security requirements at those network elements (eg, Internet of Things (“IoT”) devices) by the means of a remote agent. The security aspect of the current embodiment relates to tracking the integrity of the IoT device, including hardware/ firmware/ software (HW/FW/SW), depending on the needs and capabilities of the IoT device and derived criticality. A remote agent is disclosed and described to address multi-vendor, legacy equipment and when the IoT device or another network element cannot or does not want to bear or host a local agent. The remote agent capability is to perform integrity checking for network element(s) by probing (auditing) specific memory locations located in a tamper-proof hardware security module (HSM) in the network element. To do so, the remote agent protocol stack will include two major functional areas: collecting data and broadcasting a report. A change management system (CMS), on the operator side, is in charge of maintaining control about what to store in the network element(s) memory locations, when and how to probe such data in line with operator’s needs and responsibilities.

[0036] A remote agent is disclosed and described herein as a software element that resides within a blockchain network (BN) protocol and is designed to perform remote attestation and audits. The remote agent may also reside in an auxiliary device. The remote agent communicates with the following different entities: with the BN (an example of which is disclosed in U.S. Patent Application number 15/808,723 (hereafter the‘723 application) filed November 8, 2017, entitled“A METHOD AND APPARATUS FOR BLOCKCHAIN POWERED INTEGRITY PROTECTION SYSTEM” which is hereby incorporated by reference for all purposes as if disclosed herein) in order to validate and verify the correctness of the patches applied in a given network element; an auditor in order to perform cyclic routine checks for a set of network elements; and indirectly (via the auditor or a BN management portal) with a security operation, analytics and response (SOAR) enabled management system that performs analytics and forensics routines and finally initiates remediation in order to react to a possible mismatch (via an alarm notification) of expected versus observed integrity (breach of integrity).

[0037] Because of the design of the integrity tracking approach, the remote agent may: monitor a given network element which has absolutely no additional software installed other than the software provided by the vendor; react to malicious or unexpected changes, which have been applied to the network element thus altering its integrity because, any update to SW/FW components of the network element is compared to the actual status within the BN, and if they do not match, something happened after the last time the network element has been patched or audited successfully, and a rollback/recovery process is initiated; and report indirectly (via the auditor) to the SOAR enabled management system to, e.g., build a forensic database for security analytics such as remediation.

[0038] As a result, the remote agent may query an element and verify a patch request (stored in the BN) without requiring any external trusted third party. The remote agent will now be described in further detail.

[0039] The remote agent may be a software element that runs within an auxiliary device, external to any network element (NE), and is responsible to verify valid patch requests coming from patch initiator elements (Pis) (which have been introduced and described in the‘723 application), after being applied to a network element. In this scenario, the remote agent may only query the NE at given times (determined by the auditor), and the remote agent does not have any control/validation of the actual patch payload which the NE receives from the CMS. Note that the remote agent may be part of the BN protocol or may be locally installed on premises of the operator, or at other convenient locations.

[0040] FIG. 1 illustrates a network using BN to verify patches to a network element. The network 100 includes a BN 110, Pis 120, remote agents 130, and a NE 140. The BN includes a plurality of block chain peers 114 that are interconnected by a bus 112 implementing a peer-to- peer communication protocol. The Pis 120 interact with the BN 110 regarding patch requests and send patches to the network element 140. The remote agents 130 will be localized on a separate device from the network element 140 ne auditor

[0041] To ensure the integrity of the NE 140, the remote agent 130 requests a quote, i.e., a set of hashes representing the status of specific assets such as HW/FW/SW, contained in the F1SM of the NE 140 (usually a trusted platform module (TPM)) and groups all the received hashes within a patch report which will later be verified by the BN. The line 150 illustrates the on-chain communication, and the line 155 illustrates the off chain communication.

[0042] FIG. 2 illustrates a more detailed architecture of the BN solution, in which the remote agent is placed in the architecture as a separate device and interacts with both the BN via M7 227 messages and the NE via M6 226 messages. In FIG. 2, the network 200 may include a communication service provider 205, a SOAR 260, and the BN 110. The CSP 205 may include the PI 120, a gateway 220, the network element 140, and the remote agent 130. The gateway 220 is not a single device but an abstraction layer which is formed by several devices, one for each system replica in the BN 110, that implements communication between the PI 120, the NE 140, the SOAR 260, and the BN 110. As shown in FIG. 2, all the messages sent from Pis 120, NEs 140, and the BN are passed through the gateway 220. The gateway 220 does not implement any logic in the path creation, validation or report but is needed to establish a secure connection between the other elements of the network.

[0043] Patch requests are sent off-chain to both the NE 140 and BN peers 114 via messages M4 224 and M3 223 and messages M4 224 and M2 222, respectively. The BN peers 114 then execute the blockchain protocol to decide their orders with messages Ml 221 and write them to the blockchain (see the‘723 application for more details on this process). Flowever, messages M2 222 and M3 223 might differ, for example if an attacker is impersonating the PI 120, or the messages M2 222 and M3 223 may just be different in the order in which they have been sent out. Furthermore, as there are many different Pis 120 and each of them may be controlled by a different vendor (thus not being synchronized), so the order in which NEs 140 must apply patches might not be the same. Hence, it is of paramount importance that NEs 140 verify the patches order within the blockchain before they execute any command from Pis 120.

[0044] When a local agent is present on the NE 140, it is easy to verify the patches order and their integrity by querying the BN from within the local agent. However, as it is possible that the NEs 140 are not capable of hosting a local agent (no capability, multivendor, legacy devices, etc.), the remote agent has been designed to overcome this limitation.

[0045] FIG. 3 illustrates the message flow using the remote agent. The remote agent 130 receives message M7 227 from BN 110 and accesses the information contained in NE’s HSM 342 (eg, TPM). The goal of the remote agent 130 is to collect the status of the NE 140 by accessing the TPM or HSM 342 in a trusted manner, encapsulate the NE's status in an appropriate packet, and deliver such packet to the BN 110. The NE 140 includes an operating system/firmware layer 348 that may include a communication stack 346. Further, the NE 140 includes a hardware layer 350 that includes the HSM or TPM 342 which also includes a secure storage 344. The NE operating system is responsible for all the NE’s operations and for providing the remote agent 130 access to HW elements including HSM 342 or TPM. The HSM 342 is used to encrypt/ sign all the NE messages. In the description below, a TPM will be used as the HSM, but other types of secure modules may be used as well.

[0046] Furthermore, FIG. 3 describes the architecture of the remote agent 130 and shows the interaction among the remote agent 130 and the other elements of the BN 110 solution (see the’723 application for more details on the interaction among Pis 120 and BN peers 114). As shown in FIGs. 2 and 3 the protocol carries out the following steps. The PI 120 collects the status including dependencies of a specific NE 130 (or class of NEs) from the BN 110 via messages M4 224 and M2 222. The PI 120 sends a patch request message (PReq) to the BN 110 containing the patch request P and its dependencies via messages M4 224 and M2 222. The BN 110 validates the patch request P by checking its dependencies and returns a list L_TPM of possible TPM 342 configurations in the NE 140 that allows a safe installation of the patch so that no dependency or previous pending patch is violated via messages M2 222 and M4 224. The TPM 342 configurations may be stored in L _TPM as Merkle-tree hashes. They may be stored in other formats as well. The BN 110 also returns to the PI 120 a time window T in which the patch will be safely installed without colliding with others. The PI 120 creates a custom payload for the patch P where the first part is L_TPM, the second part is P, the patch itself, and the last part is a set of commands C to write in the TPM 342 the hashed results of the patching process via messages M4 224 and M3 223 and M8 228. Note that the PI 120 is responsible for what to monitor until the patching process is completed, and the payload must arrive and be applied at the NE 140 within the time window.

[0047] The NE 140 receives the custom payload from PI 120 and executes the following conditional steps: if the TPM 342 contains a state matching an entry in L_TPM then apply the patch; and after the patch is applied, execute the commands in C to memorize in the TPM 342 the updated/patched state of the NE 140 via message M8 228. This procedure provides a remote assessment protocol using the remote agent 130.

[0048] The BN 110 sends the PReq metadata (M) to the remote agent 130 via the auditor 218 indicating which state to expect after quoting the TPM 342 of the NE 140, and after the time T the quote should indicate that the patch P was successful via messages M7 227. The remote agent 130 initiates the quoting procedure against the NE 140 after time T to collect the TPM 342 stored hashes via message M6 226. The NE 140 sends the hashes to the remote agent 130 via message M6 226. The remote agent 130 collects the hashes as indicated in the PReq metadata. Then, it creates and sends to the BN 110 a valid patch result message (PRes) to be appended to the blockchain, in order to confirm by the BN, the successful patching process of the NE 140 via message M7 227. If the BN determines that the PRes matches the PReq, then the PRes is appended to the blockchain in the BN 110 and the patching is successful. Otherwise, the corresponding PRes is discarded and a flag is raised to the issuing PI 120 and/or relevant management system, e.g., SOAR, via messages M2 222 and M5 225.

[0049] A more detailed operation of the TPM 342 will now be provided. The TPM is described by Trusted Computing Group (TCG) documentation. This section details an embodiment of the use of a TPM in the environment described above. The secure storage 344 of the TPM 342 may include platform configuration registers PCRs.

[0050] The NE 140 includes a TPM 342 and provides an interface such that certain details stored upon the TPM 342 may be obtained. At minimum, this interface provides the ability for a quote to be taken so that the remote agent 130 may request a quote of the necessary PCRs. Other parameters such as the nonce, key selection, hashing function, etc. may be provided. The interface may be provided using any suitable means. The remote agent 130 must be able to take a quote of the NE 140 and check the signature of that quote against a suitable signing key - typically the TPM's attestation key - and check the attested value and associated meta-data against known good values and additionally against historical states.

[0051] It is assumed that a suitable introduction protocol is available such that the NE’s data, in particular its identity, the public key of the endorsement key (EKpub), and the public key of the attestation key (AKpub) are available to the remote agent 130 (usually provided by the PI 120 when registering the patch within the BN 110 or provided directly to the remote agent 130). The identity of the NE 140 may be obtained as a function over the EKpub/AKpub public keys, attestation cert or any other strong or global identity mechanism associated with the TPM on that device. In other words, it is assumed that proper identification/ authentication and authorization of the device’s HSM/TPM is guaranteed.

[0052] When the remote agent 130 operates during a patching session, the following communication takes place in one implementation and embodiment. The remote agent 130 receives the metadata M to check the status of the NE 140 from the BN 110 via message M7 227. The remote agent 130 takes a quote of the NE 140 by using the metadata M to access the TPM 342 and collect the correct PCRs via message M6 226 and eventually message M8 228 if there is no direct interface with the TPM 342. The remote agent 130 sends the signatures, attested values and other associated data to the BN 110 via message M7 227, encapsulated as a PRes. The BN 110 checks the outcome of the patch PRes against the PReq stored in the blockchain, and informs PI 120 (and eventually the management system) of the current state of the NE 140.

[0053] A complete sequence of this operation is as follows where RA is the remote agent

130:

PI->BN: request to update NE with patch P

BN->PI: approve patch P and initiate patching

BN->RA: attest NE (after time T)

PI->NE: apply patch P

NE: patch P applied (within time T)

RA->NE: quote (after time T)

NE->RA: quote "q" of NE's state after patch P in PCRs, signature "s"

RA->BN: quote and signature (q,s) encapsulated as a PRes BN: check if PRes is matched by PReq

BN->PI/SOAR: patch applied successfully (or not)

[0054] It should be apparent from the foregoing description that various exemplary embodiments of the invention may be implemented in hardware. Furthermore, various exemplary embodiments may be implemented as instructions stored on a non-transitory machine-readable storage medium, such as a volatile or non-volatile memory, which may be read and executed by at least one processor to perform the operations described in detail herein. A non-transitory machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal or laptop computer, a server, or other computing device. Thus, a non-transitory machine-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media and excludes transitory signals.

[0055] It should be appreciated by those skilled in the art that any blocks and block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Implementation of particular blocks can vary while they can be implemented in the hardware or software domain without limiting the scope of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in machine readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0056] Accordingly, it is to be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications other than the examples provided would be apparent upon reading the above description. The scope should be determined, not with reference to the above description or Abstract below, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the application is capable of modification and variation.

[0057] The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

[0058] All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those knowledgeable in the technologies described herein unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as“a,”“the,”“said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

[0059] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

Claims

What is claimed is:

1. A method for accepting and verifying a patch request to patch a network element from a patch initiator using a remote agent, the method comprising:

receiving, by the remote agent, a request from a blockchain network to check the patch status of the network element;

sending, by the remote agent, a patch status request to the network element;

receiving, by the remote agent, the patch status from the network element; and transmitting, by the remote agent, the patch status of the network element to the blockchain element.

2. The method of claim 1, wherein the patch status is received from a secure storage in the network element.

3. The method of claim 1, wherein the remote agent sends the patch status request after a time window T.

4. The method of claim 3, wherein the blockchain network sends the time window T to the patch initiator.

5. The method of claim 4, further comprising patching the network element by the patch initiator in the time window T.

6. The method of claim 1, wherein the patch status is a hash.

7. The method of claim 1 , further comprising:

sending, by the patch initiator, a patch request to the blockchain network including patch dependencies.

8. The method of claim 7, further comprising:

validating, by the blockchain network, the patch request; and

sending, by the blockchain network, to the patch initiator a list of possible configurations of a hardware security module in the network element based upon the patch request.

9. The method of claim 8, further comprising:

sending, by the patch initiator, to the network element a payload including the list of possible configurations, a patch for the network element, and a set of commands to write the result of the patching process to the hardware security module.

10. The method of claim 9, wherein, the BN verifies that the network element has been patched within a time window T specified by the blockchain network.

11. The method of claim 1, wherein remote agent resides in the blockchain network.

12. The method of claim 1, wherein, the remote agent resides in a network device separate from the network element.

13. A non-transitory machine-readable storage medium encoded with instructions for accepting and verifying a patch request to patch a network element from a patch initiator using a remote agent, comprising:

instructions for receiving, by the remote agent, a request from a blockchain network to check the patch status of the network element;

instructions for sending, by the remote agent, a patch status request to the network element;

instructions for receiving, by the remote agent, the patch status from the network element; and

instructions for transmitting, by the remote agent, the patch status of the network element to the blockchain element.

14. The non-transitory machine-readable storage medium of claim 13, wherein the patch status is received from a secure storage in the network element.

15. The non-transitory machine-readable storage medium of claim 13, wherein the remote agent sends the patch status request after a time window T.

16. The non-transitory machine-readable storage medium of claim 15, wherein the blockchain network sends the time window T to the patch initiator.

17. The non-transitory machine-readable storage medium of claim 16, further comprising patching the network element by the patch initiator in the time window T.

18. A remote agent device for use in accepting and verifying a patch request to patch a network element from a patch initiator, comprising:

memory; and

a processor connected to the memory, the processor configured to:

receive a request from a blockchain network to check the patch status of the network element;

send a patch status request to the network element;

receive the patch status from the network element; and

transmit the patch status of the network element to the blockchain element.

19. The remote agent device of claim 18, wherein the patch status is received from a secure storage in the network element.

20. The remote agent device of claim 18, wherein the remote agent sends the patch status request after a time window T.

21. The remote agent device of claim 20, wherein the blockchain network sends the time window T to the patch initiator.

22. The remote agent device of claim 18, wherein the remote agent device resides in the blockchain network.

23. The remote agent device of claim 18, wherein the remote agent device resides in an auxiliary device separate from the network element.