Merge pull request #68 from nqminds/restructure-for-CAHN

Restructure for cahn

.vscode/settings.json

@@ -1,12 +1,15 @@
 {
   "cSpell.words": [
+    "Allott",
     "BRSKI",
+    "CAHN",
     "hostapd",
     "MASA",
     "nquiringminds",
     "offboard",
     "offboarding",
     "onboarded",
+    "Prolog",
     "tdxvolt",
     "webserver",
     "WIFI",

packages/docusaurus/docs/CAHN/10-intro.md

@@ -0,0 +1,32 @@
+---
+slug: /
+title: Introduction
+---
+
+Nquiringminds is developing Continuous Assurance for Heterogeneous Networks (CAHN). New technology that underpins network-of-networks, with novel identity models and zero-trust security. [[1](https://www.ukri.org/news/major-future-telecoms-research-boost-announced/#:~:text=UKRI%20is%20investing%20%C2%A370,foundational%20role%20in%20communication%20networks.)]
+
+Nick Allott, CEO of NquiringMinds comments: “Our concept of continuous assurance, builds on some innovative work that has been developed within NIST" [[2](https://www.nccoe.nist.gov/projects/trusted-iot-device-network-layer-onboarding-and-lifecycle-management)]
+
+CAHN will develop new architectures working across networks. It will use advanced nations of identity and distributed credentials, combined with dynamic (AI) reasoning to dynamically infer trustworthiness and assurance. We will work with many different use case and endpoints, with use cases that include Digital Secure by Design hardware silicon to protect against memory vulnerabilities developed with ARM and University of Cambridge. [[3](https://www.dsbd.tech/)][[4](https://www.arm.com/architecture/cpu/morello)]
+
+## Verifiable Credential Technology
+
+CAHN will be a system which can take in information from many sources and through many channels through the use of Verifiable Credential (VC) technology. With traditional secure communication, such as online banking, the channel by which you communicate information is secured (e.g. the https connection made to your online banking provider of choice, established via standard PKI technology). Using verifiable credentials you instead secure the information you are communicating itself by using PKI technology to sign the packets of information. The advantages of this approach are:
+
+- the information can come via unsecured or out-of-band mechanisms and the information's content can still be tamper-proof and it's source may be cryptographically attested to and verified.
+
+- the provenance of the information may be attested to and tracked, VCs themselves may be signed and attested to as VC recursively, which may be utilised as a method to attest to the mechanism and routes by which the information came into the system.
+
+- By storing the data as VCs then the provenance of each piece of information's origin is maintained, and can be retrospectively reasoned about post receipt of the information. By virtue of this one can also introspect on the VCs issuers to gain insights into the issuers, for example the trustworthiness of those issuers, or the kinds of information they provide, and can model their behaviour to spot unusual activity.
+
+- users consuming data from a system which embodies it's data as VCs can choose which VC issuers and routes to trust, and the time period / conditions in which they trust them. Each user may therefore have a different view of the same data by trusting different VCs, the data host does therefore not impose their own world view of concept of trust onto system users, they gain the autonomy to decide for themselves what information they believe.
+
+- Use of VCs facilitates multiple decentralised signing authorities, rather than relying on one central authority to secure the route via which data enters your system. This mitigates the risks of a central authority being compromised and decouples you from relying on a single providers services, freeing data providers being reliant on a single central source. This also facilitates self-signing of information, supporting the self-sovereign identity model, which gives individuals full ownership and control of their digital data and identity.
+
+- Because the information itself is signed distributed storing of data becomes much easier, as it can be re-communicated and distributed between data lakes later, while maintaining the security and provenance of the information. 
+
+# Continuous Assurance 
+Another piece of our solution is continuous assurance, that is, *continuously* examining the claims made to the system to see if we still believe those piece of information and their sources, and *assuring* that the data and its sources are still trustworthy. Rather than relying on a one-off assurance event the system will continuously apply multiple multiple analytical techniques to infer the trustworthiness and validity of the information claimed to the system.
+
+This can be configured to work differently for each data-consuming user in the system, rather than being a top down authoritative approach of prescribing to users what facts, issuers or routes they should trust, we give the freedom to users to configure their own thresholds and metrics for what information, routes of data provenance and issuers they should trust.
+

packages/docusaurus/docs/CAHN/20-uses-cases.md

@@ -0,0 +1,3 @@
+---
+title: Use Cases
+---

packages/docusaurus/docs/CAHN/30-architecture/10-claim-flows.md

@@ -0,0 +1,15 @@
+---
+title: Claim Flows
+---
+
+Every piece of information communicated to the system will be claimed in the form of a verifiable credential, and signed by the private key of the user making the claim (henceforth called the claim issuer). Where this signing takes place is completely optional, for example below we've outlined several different schemes by which the VC may be produced, signed and send to a node set up to receive the VC, with differing levels of locality, from everything performed on a local machine, including a node on the local machine, to a user authoring and signing the claim entirely through a web interface.
+
+![image](./CAHN_Architecture_Claim_production.png)
+
+The VC may be communicated to the a node of the system via a number of different routes, for the simplest example lets assume a REST API endpoint is present on the node which may receive VCs. The VC will be verified to check that it was signed by the private key of the user and that the information contained within has not been tampered with. Next the VC may optionally be propagated to other nodes on the system (encapsulated within a VC signed by the node which received the VC). The next step is that the VC is parsed by the trust engine to determine whether the VC is trusted to make inferences upon, this trust engine may be differently configured on different nodes of the system, if the trust engine determines that the VC is trusted it is passed to the next stage of the system. The next stage of the system parses the information in the verifiable credential and translates it into the appropriate Prolog representation, and updates the current Prolog inferencing environment of that node, such that the encapsulated information may be used to perform inferences.
+
+![image](./CAHN_architecture_VC_receiving.png)
+
+In this way each node of the system can pass verified information to each other node of the system, and the route by which it got to that node of the network (the provenance of that claim) may be cryptographically attested to by the nesting of VCs.
+
+![image](./CAHN_architecture_network_distribution.png)

packages/docusaurus/docs/CAHN/30-architecture/20-claim-system-design.md

@@ -0,0 +1,36 @@
+---
+title: Claim Cascade Design
+---
+
+## Generation and storage of key-pairs for Signing of VCs
+
+The claim cascade system is designed such that users or automated agents may sign claims with their private key (stored locally or stored on a remote server which for signs the claims on the user's behalf), the only requirement for the VC to be verifiable is that public key paired with the private key which was used to perform the signing will need to be securely shared in a trusted way with the system, such that the public key can be tied to a particular user's identity. 
+
+This will be achieved by utilising an authentication server which can be sent a request to generate a VC binding a public key to a user's identity, this request will contain the public key and a users credentials, in the most simple case, an email address. These credentials will then be verified, for example in the case of email; the user will receive an email which contains a link they must click to prove their identity, once that is completed the authentication server will sign a VC with it's own private key, which is trusted bt the system, binding the user's identity to that public key. This can be submitted to the system by the user to allow them to submit further VCs signed with their private key.
+
+The management of their keys then becomes an implementation detail which can be specified by the user, private-public key pairs may be ephemeral and generated 
+
+## Receipt of VCs
+
+VCs will be submitted to a particular Claim Cascade node (running on a router / access point for example) through a HTTPS REST API endpoint. The VC will then be stored in an append only return as a received VC on that node using an Event Sourcing pattern. This means that once received a record of all the VCs received will be maintained and if our trust basis or verification basis changes one could regenerate the entire state of the system from the received VCs.
+
+## Verification of VCs
+
+Once a new VC has been received it will be stored on the node and a verifier process will start, which runs on that VC to verify that the VC was signed by the issuer (the VC issuer is specified in the VC) and has not been tampered with, this requires the verifier to have access to the public key of the issuer, which requires it to have been communicated through a trusted method to the node, or for the node to have access to, and trust, a server which has a record of the pubic key of the issuer. Once a VC is verified it may be passed onto the next stage of the process, which is the trust engine, it may also at this stage be signed by the node's public key as a VC and communicated to other nodes on the system, so they can process the information claimed within. 
+
+## Trust Engine
+
+The verification step above merely checks that the VC was signed by the issuer contained within and that it has not been altered since signing, it doesn't say anything about whether the issuer of that VC is trusted to be making claims to this node. The trust engine's purpose is to resolve whether we should trust the information contained within the VC and use the information contained within to perform inference. The details of the algorithm to use to determine if we trust the VC issuer is still in development and discussion but the idea is to use the following information to infer whether the issuer is to be trusted:
+- which other users trust or distrust the issuer, and the trust we have in those users
+- which claims this issuer has submitted in the past
+
+## Trusted VC to Inference Environment
+
+The VCs which are trusted are then passed to a utility which generates the code in Prolog for the information contained within the VC. The VCs which may be submitted here come in 4 types:
+
+- schema - this defines the schema for a fact which may be submitted, for example, for a fact that a device has a vulnerability the schema defines how that fact is structured, i.e. what fields are associated with this fact and any constraints on the values which may be entered for each field. 
+- fact - this defines a fact which should be added to the inferencing environment to be reasoned about, the fact structure should match a schema submitted to the system, for example a fact that a device has a vulnerability
+- retraction - a statement that a user retracts a previously submitted fact, used to retract falsely submitted information
+- rule - this defines a rule, which defines the logic used for inference, for example a rule may be that a device is not allowed to connect to this wifi router if it has a vulnerability with a score higher than a certain threshold. 
+
+Using these building blocks one may build any general inferencing system.