Interfaces specification. In Table 4 we show an initial draft version for Systemic VNF Wrapper controller interfaces. Method URL Required Data Objects Returned Data Object POST /systemic/analyse/ input binary file Binary Analysis JSON POST /systemic/protect/ JSON protection project input binary file Zip Compressed Archive PUT /systemic/patch - metadata/ JSON metadata descriptor Protected binary file Zip Compressed Archive POST /systemic/get - metadata/ JSON metadata descriptor Protected binary file Decrypted Metadata Content Table 4: Systemic VNF Wrapper API The version returns a plain JSON object which contains the following fields: Name Description Sample value success Request success (boolean) true | false version Protection server version (string) 21.07.01 build_time Protection server build date time (string) 2021- 07- 21 11:40:05 Table 5: Systemic JSON file content &Žƌ ƐƚĂŶĚĂƌĚ ^LJƐƚĞŵŝĐ ƉƌŽƚĞĐƚŝŽŶƐ͕ ŝƚ ŝƐ - ƐƵĨĨŝ ĚĂƚĂ͟ -tĐypŽe,ŶtoƚthĞe Ŷprƚotect URL, containing the input-binary file and an optional protection settings JSON file. The stub of a JSON protection project contains the following fields: Name Description Sample value systemic Enables Systemic (boolean) true | false sgx Leverage Intel SGX enclave (boolean) true | false encryptionsymmetrickey The AES key used to encrypt the binary (string) AES- 128 for Systemic SGX AES- 256 for Systemic 8596d827dba716[...] signingprivate The RSA key used to encrypt the binary (string) ----- BEGIN RSA PRIVATE KEY[...] RSA- 3092 for Systemic SGX RSA- 4096 for Systemic metadatakey The AES key used to encrypt metadata (string) AES- 128 for Systemic SGX AES- 256 for Systemic b0a2e848fca09cf8b[...] metadata The metadata content (string) Test 123 Table 6: Protection project stub The request returns a Zip Compressed Archive that contains the output Protected Binary File together with a JSON formatted report of the protection. The report JSON file includes the following fields: Name Description Sample value success Protection success (boolean) true | false project The supplied protection project (JSON object). If no Systemic keys where supplied, the ones generated at random by the protection servers will be shown here. Refer to Table 4 Protection project stub version The protection server version (string) 21.07.01
Interfaces specification. The external PoT controller API interfaces is shown in Table 8. Method URL Required Data Objects Returned Data Object GET /pot/controller/path/{uuid} UUID Path JSON POST /pot/controller/path --- Path JSON DELETE /pot/controller/path/{uuid} UUID --- Table 8: Proof of Transit API They are designed to create, monitor and destroy the PoT. Returned objects contains detailed information of the created path and their status. One example is shown in Figure 21. {
Interfaces specification. The eTRM is in charge of assessing the reputation values of a given SDN domain, including its own SDN controller and interconnected nodes (switches and hosts). The key parameters related to our enabler are the following: timeslot: contains the time of the day (int64) given as input to build the graph nodeId: the ID of the node. It can be an SDN controller, a host or a switch. sourceNodeId and targetNodeId: Identifiers of links, those IDs are referring to existing nodeIDs Three types of links are considered in eTRM: switch-switch link host-switch link controller-switch link (control link) eTRM can provide several JSON objects (see Figure 24 and Figure 25) as response to several GET requests, all schematized in the following Table 9. Method URL Required Data Objects Returned Data Object POST /trust/trm/reputation/{timeSlot}/pgm timeSlot (int64) -- GET /trust/trm/reputation/{timeSlot}/domain reputation timeSlot (int64) Reputation graph (JSON) GET /trust/trm/reputation/{timeSlot}/node/{ nodeId} timeSlot (int64) nodeId (int64) Reputation value for that given nodeId (JSON) GET /trust/trm/reputation/{timeSlot}/link/{ sourceNodeId}/{targetNodeId} timeSlot (int64) sourceNodeId (int64) targetNodeId (int64) Reputation value for that connection/link( JSON)
Interfaces specification. At design time, CCT is used as a standalone tool for evaluating any type of components. It is used as a tool and no API is provided. At run time, the interface of CCT is used for giving the list of DTwC with the different trust metrics for the different components. It is possible to retrieve only one DTwC based on its UUID or it is possible to retrieve all DTwC. It could be used at E2E service management domain level. Method URL Required Data Objects Returned Data Object GET /rest/files/type/{componentID} UUID text (DTwC) GET /rest/files/searchHashs/{ type} type (string) JSON object GET /rest/files/downloadDTwCByHash/{ hash} hash (string) text (DTwC) POST / CertificationRepository/rest/files/ uploadDTwCs?VNFType=type" file (DTwC) -- Table 10: Component certification tool API By this way, CCT will give different trustworthiness properties for the components involved in the slice.
