The CBS architecture consists of three main components:
-
Producer - this component creates Digital Containers by adding protection to data by applying an encryption operation and/or attaching a digital signature. The digital container can be stored or sent with no restrictions. The content is still protected and the key must be retrieved from the Broker.
-
Consumer - this component is used whenever access to the data is needed. It requests the decryption keys from the Broker and extracts data from Digital Containers by removing protection from data by applying a decryption operation and/or verifying an attached digital signature.
-
Broker - this component regenerates keys required to decrypt the data inside Digital Containers. The Broker uses the Access Control GE[1] to check the user’s credentials and the information about the data object against a set of policies of use.
The CBS OGE offers two interfaces:
-
Protect - This interface, offered by the Producer, is used to request the protection of data. A request to protect data includes the data to be protection, metadata, headers and the protection mode and returns the protected Digital Container.
-
Unprotect - This interface, offered by the Consumer, is used to request the removal of protection from data in a digital container. The user sends the protected Digital Container to the CBS OGE. The metadata in the Container is used to determine whether a particular user is authorised to remove protection from the data.
The CBS OGE uses the following concepts:
-
Digital Container - this is a wrapper document that protects digital content with an encryption algorithm and/or a digital signature. In addition to the protected content, the Container also encapsulates the protection mode, metadata, headers, a unique container ID, and additional parameters required to extract the unprotected payload (e.g. cipher transformation, and algorithm parameters).
-
protection mode - this is the type of protection to apply to the container. The acceptable values are: ENCRYPT - encrypt the container; SIGN - sign the container; and SIGN_THEN_ENCRYPT - sign the container and then encrypt it.
-
metadata - this is a a set of attribute-value pairs that includes labels that can be used to determine whether a particular user is authorised to protect the data, e.g., the classification or category of the data. The metadata may be used to determine the type of protection to apply, e.g., the choice of encryption algorithm or key.
-
headers - this is a set of attribute-value pairs that provide additional parameters to be included in the container. They may contain information on how to reconstruct the protected data, e.g. the mime-type or the filename extension.
23.5.1Example Scenario
There is a major fire incident at a shopping mall. Alice is the Chief Fire Officer at the Command and Control Centre. She needs to share some information about the incident with some of the Fire Fighters on the ground. She wants to protect the information to make sure that only Incident Commanders can access it. Alice generates labels describing the information. She uses the CBS Producer service to encrypt the data and includes the metadata in the request. The CBS Producer generates an encryption key and encrypts the data. It returns the encrypted data to Alice, who then publishes the encrypted data.
Bob, an Incident Commander receives the protected data and uses the CBS Consumer to access the data. He sends the encrypted data to the CBS Consumer along with his credentials. The CBS Consumer requests the decryption key from the CBS Broker service. The Broker sends a request to the Access Control GE[1] to authorise the request to access the information. Bob is authorised to access the information, as he has the role of Incident Commander, so the CBS Consumer generates the decryption key and decrypts the data. It then returns the decrypted data to Bob.
Charlie, who is a Fire Fighter, also receives the protected data. He uses the CBS Consumer to access the data, sending the protected data and his credentials to the CBS Consumer. The CBS Consumer requests the decryption key from the CBS Broker service. The Broker sends a request to the Access Control GE to authorise the request to access the information. Charlie is not authorised to access the information, as he does not hold the role of Incident Commander. The CBS Consumer returns a ‘rejected’ decision to Charlie.
Alice needs to share information about the incident with the Police Service. Dave, an Incident Commander with the Police Service receives the protected data and uses the Police Service’s CBS Consumer to access the data. The CBS Consumer requests the decryption key from the CBS Broker service in the Police Service’s domain. Since the data was protected in the Fire Service’s domain, the Police Service’s Broker refers the request for the decryption key to the Fire Service’s Broker, which then sends a request to the Access Control GE [1] to authorise the request. Dave is authorised to access the information, as he has the role of Incident Commander, so the Fire Service’s CBS Broker generates the decryption key and sends it to the Police Service’s Broker. The Police Service’s Broker sends the decryption key to the Consumer, which decrypts the data and returns it to Dave.
23.6Main Interactions
It is advisable to consider using a secure connection, e.g. using Transport Layer Security (TLS), when interacting with the CBS OGE.
23.6.1Protecting Data
The protect interface enables a user to encrypt and/or sign data. The user uses the Identity Management GE to authorise an application to act on their behalf. The application sends the data to be protected, the metadata and the data protection mode (e.g. Encrypt, Sign or EncryptAndSign) to the CBS Server along with an access token from the Identity Management GE. The Producer validates the token and may request an authorisation decision from the Access Control GE as to whether the user is allowed to perform the requested operation. If the user is authorised, the CBS Producer generates a key and then protects the data. The protected data is returned to the user in a Digital Container. A sequence diagram for the protect interaction is shown below.
User protects data
23.6.2Removing Protection from Data
The unprotect interface enables a user to decrypt and/or verify the signature of a Digital Container. The user uses the Identity Management GE to authorise an application to act on their behalf. The application sends the container to be unprotected to the CBS Server along with an access token from the Identity Management GE. The container encapsulates the protection mode, e.g. ENCRYPT or SIGN, and additional parameters required to remove protection from the data, e.g. the cipher algorithm and the cipher mode. . The access token contains attributes about the end user, e.g. their role. The Consumer sends both the access token and metadata from the container to the CBS Broker with a request for the decryption key. The CBS Broker checks whether to refer the request for a decryption key to a Broker in another domain. If referral is not needed, it uses the Access Control GE to authorise the request. If the request is accepted, the Broker regenerates the key needed to remove protection from the container and returns it to the CBS Consumer. The CBS Consumer then removes protection from the data. A sequence diagram for the unprotect interaction is shown below.
User removes protection from data
Share with your friends: |