We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Security.Optional Security Enablers.ContentBasedSecurity - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.Optional Security Enablers.ContentBasedSecurity

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.Optional Security Enablers.ContentBasedSecurity
Chapter Security,
Catalogue-Link to Implementation [N/A ]
Owner Thales, Richard Egan



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2013 by Thales

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.



Content-Based Security (CBS) refers to the concept of protecting data and its metadata at its source and integrating access control in a managed way. The data is protected (e.g. by encrypting or signing) at the time of its creation. The cryptographic means, e.g. the algorithm or key, is chosen according to the sensitivity of the data. Instead of controlling access to the information at processing entities, access to the data is managed by restricting access to the cryptographic material needed to remove protection from the data. This type of content protection allows the data to be freely distributed over the physical networks.

The Content Based Security Optional Generic Enabler (OGE) API provides services that protect and remove protection from data. It has three services: the Producer, the Consumer and the Broker. The Producer protects the data by encrypting and/or signing the data, depending on which operations were requested. Each Producer has a relationship with a Broker, which is referred to as the producer's native key broker. When this relationship is established (which may be an offline process), they exchange keys. This enables the key broker to be able to regenerate the keys used to protect containers.

The Consumer is used to remove protection from the content of digital containers by applying a decryption algorithm and/or verifying the digital signature. Each Consumer has a relationship with a Broker, which is referred to as the consumer's native broker. A Consumer applies to its native broker for the digital container’s decryption key.

Brokers process each request for a decryption key by using the Access Control GE to reach an automated decision on whether to grant the container consumer access to the decryption key. A Consumer is only able to open the digital container and view its contents if the key broker provides the decryption key.

Content Based Security OGE Block Diagram

Support for Multi Domain Deployments

A Security Domain is a collection of Producers and Consumers that have a relationship with a single Broker. The CBS OGE is able to support deployments consisting of more than one security domain. A Broker can only regenerate keys for containers that were protected by Producers in its security domain. If a key request relates to a digital container that was generated by a Producer in a different Security Domain, the broker refers the request to the Producer’s native broker. This implies that trust relationships must exist between key brokers in different Security Domains. However, trust relationships between container producers and container consumers (either in the same Security Domain, or in different domains) are not necessary; hence the solution is scalable to large numbers of producers and consumers.

Support for multiple domains is important where data produced by one enterprise is protected and then made available for consumption by other enterprises. To support this model, the concept of a referred key request is introduced. This involves an instance of the CBS OGE in one domain referring a request for a container decrypt key to an instance of the CBS OGE in another domain. The mechanics of the multi domain model are show in the figure below and are described below, using the example of Enterprise A producing containers that are subsequently consumed by Enterprise B.


Target Usage

The Content Based Security OGE is used to apply protection, e.g. encryption and/or signing, at the application layer to items of data (mp3, jpeg, .doc, etc.). It controls access to content in an information container, rather than controlling possession of the information container. This provides:

  • Medium, content and channel independent protection
  • Protection at rest or in flight
  • Fine-grained control

It cryptographically attaches metadata to the protected data items to give:

  • Cradle to grave protection
  • Sticky policies

It controls access using policy based authorisation so that:

  • I let you have the key for information I want to share with you
  • I just let you see the metadata for information I don’t want to share with you
  • I put the information that I don’t want you to know that I’ve got inside another layer of protection

Basic Concepts

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.

Example 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.

Main Interactions

It is advisable to consider using a secure connection, e.g. using Transport Layer Security (TLS), when interacting with the CBS OGE.

Protecting Data

The protect interface enables a user to encrypt and/or sign data. The user sends the data to be protected, the metadata and the data protection mode (e.g. Encrypt, Sign or EncryptAndSign) to the CBS Server. The CBS Producer 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. Sequence diagrams for the protect interaction are shown below.

User is authorised to protect data

User is not authorised to protect data

Removing Protection from Data

The unprotect interface enables a user to decrypt and/or verify the signature of a Digital Container. The user sends the container to be unprotected to the CBS Server. 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 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. Sequence diagrams for the unprotect interaction are shown below.

User is authorised to remove protection from data

User is not authorised to remove protection from data

The follow sequence diagrams show a scenario where two security domains are involved.

Referred request where user is authorised to remove protection from data

Referred request where user is not authorised to remove protection from data

Basic Design Principles

The CBS OGE applies protection directly to content. This offers a number of advantages. The content is protected throughout its lifetime, regardless of what communication links it is transferred over, or how it is stored during that time. By not controlling access at the level of network or system connections, it becomes easier to share information. The data produced by systems is protected regardless of what other systems or networks they are connected to, thus allowing more systems to connect to and communicate with each other without harming security of their data. Fine grain protection and access control is now possible; protection can be applied to paragraphs or sections within documents, fields within data structures or frames of a video, for example. Applying protection to data can be significantly more efficient and the architecture scales well to large amounts of information with large numbers of producers and consumers. Data need only be protected once for all possible end-users, without the overheads of having to set up secure tunnels between producers and each potential endpoint.


  1. 1.0 1.1 1.2 FIWARE.OpenSpecification.Security.Access Control Generic Enabler

Detailed Open Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labelled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labelled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Other Open Specifications

Re-utilised Technologies/Specifications

The Content-Based Security Optional GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1
  • JSON and XML data serialization formats

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Attack. Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself
  • Authentication protocol: "Over-the-wire authentication protocols are used to exchange authentication data between the client and server application. Each authentication protocol supports one or more authentication methods. The OATH reference architecture provides for the use of existing protocols, and envisions the use of extended protocols which support new authentication methods as they are defined." (OATH)
  • Access control: is the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. (ITU-T-X-800_Link). More precisely, access control is the protection of resources against unauthorized access; a process by which use of resources is regulated according to a security policy and is permitted by only authorized system entities according to that policy. RFC 2828
  • Account: A (user) account is “typically a formal business agreement for providing regular dealings and services between principal sand business service providers.” OASIS Security Assertion Markup Language (SAML)
  • Authentication (AuthN): We adopted the following definition of authentication from RFC 3588"Authentication is “the act of verifying the identity of an entity (subject)”
TrustInCyberspace adds the term “level of confidence” to this definition:
Authentication is the process of confirming a system entity’s asserted identity with a specified, or understood, level of confidence.” This definition holds all necessary parts to examine authentication in broad sense. First of all it does not narrow the authentication to human users, but refers to a generic “system entity”. See authentication reference architecture description for a closer look at different identities that could be authenticated.
Secondly it introduces the often neglected concept of “level of confidence” which applies to each authentication of an identity. No computer program or computer user can definitely prove the identity of another party. There is no authentication method that can be secured against any possible identity-theft attack, be it physical or non-physical. It is only possible to apply one or more tests, which, if passed, have been previously declared to be sufficient to go on further. The problem is to determine which tests are sufficient, and many such are inadequate.
The original Greek word originates from the word 'authentes'='author'. This leads to the general field of claims and trust management, because authentication could also mean to verify the “author” / issuer of any claim.
The confirmation or validation process of authentication is actually done by presenting some kind of proof. This proof is normally derived from some kind of secret hold by the principal. In its simplest form the participant and the authentication authority share the same secret. More advanced concepts rely on challenge/response mechanisms, preventing the secrets to be transmitted. Refer to Authentication Technologies for a detailed list of authentication methods used today.
As stated above, each authentication method assures only some level of trust in the claimed identity, but none could be definite. Therefore it makes sense to distinguish the different authentication methods by an associated assurance level, stating the level of trust in the authentication process.
As this assurance level depends not only on the technical authentication method, but also on the overall computer system and even on the business processes within the organization (provisioning of identities and credentials), there is no ranking of the authentication methods here.
  • Countermeasures. Action, device, procedure, technique or other measure that reduces the vulnerability of an information system.
  • Cyber attack. An attack, via cyberspace, targeting an entity (industrial, financial, public...) and using cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information
  • Exploit. A program or technique that takes advantage of vulnerability in software and that can be used for breaking security, or otherwise attacking a host over the network
  • Federation: The term federation “is used in two senses - "The act of establishing a relationship between two entities. An association comprising any number of service providers and identity providers.” OASIS Security Assertion Markup Language (SAML)
“A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on an identity, and possibly associated attributes, that are asserted in another realm.
Federation requires trust such that a relying party can make a well-informed access control decision based on the credibility of identity and attribute data that is vouched for by another realm.” WS-Federation @ IBM
Remark: Federation according to WS-Federation @ IBM is similar to the concept of a Circle of Trust.
  • FI. Future Internet.
  • Forensics for evidence. The use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation and presentation of digital evidence derived from digital sources for the purpose of facilitating or furthering the reconstruction of events found to be criminal, or helping to anticipate unauthorized actions shown to be disruptive to planned operations.
  • Identity. In the narrow sense, identity is the persistent identifier of users (user name), things or services by which other parties “remember” them and, hence, are able to store or retrieve specific information about them and are able to control their access to different resources. In the wider sense, identity also covers further attributes of users, things and services; e.g. for users, such information may include personal information such as context, group membership and profile.
  • Identity (Digital): The term identity and its meaning have been discussed controversially in the “identity community” for many years. Until now, there is no commonly agreed definition of that notion. : : The IdM && AAA reference architecture applies the following three definitions of identity.
The Identity Gang defines the term digital identity as follows:
A digital identity is “a digital representation of a set of Claims made by one party about itself or another digital subject.”
The following comments were added:
A digital identity is just one set of claims about a digital subject. For any given digital subject there will typically be many digital identities.
A digital identity can be created on the fly when a particular identity transaction is desired or persistent in a data store to provide a representation that can be referenced.
A digital identity may contain claims made by multiple claimants.
A digital identity may be signed by a digital identity provider to provide assurance to a relying party.
This definition emphasizes two facts:
Normally, a principal (subject) has multiple digital identities or personas.
Identities are made out of attributes (claims).
Therefore, the scope of identity management in the reference architecture has two viewpoints: For once it focuses on identities and personas itself, and on the other side, it deals with the attributes of these identities and personas.
The Liberty Alliance Project (LAP) defines digital identity as follows:
Digital identity is “the essence of an entity. One’s identity is often described by one’s characteristics, among which may be any number of identifiers. A Principal may wield one or more identities.”
RSA uses the following definition of digital identity:
“Digital identity consists of an identity assertion and the characteristics, sometimes called attributes that are collected or observed through our computerized relationships. It is often as simple as a user name and password.”
The definition of RSA adds one important aspect to the identity discussion: Even the simplest user name and password combinations without any additional attributes or claims constitute an identity.
  • Identifier: Identifiers can be understood as a dedicated, publicly known attribute of an identity that refers to that identity only. Typically, identifiers are valid within a specific domain. Special types of identifiers are valid globally, due to the use of popular domain naming and resolution protocols such as DNS, which implies addressing capabilities to the identity. OASIS Security Assertion Markup Language (SAML) defines identifier as follows:
An identifier is “a data object (for example, a string) mapped to a system entity that uniquely refers to the system entity. A system entity may have multiple distinct identifiers referring to it. An identifier is essentially a "distinguished attribute" of an entity.”
  • Identity context: is “the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions.” (Identity Gang)
  • Identity management (IdM): comprises “the management of identity information both internally and when it is passed from one entity to another.” Open Mobile Alliance (OMA)
  • Identity provider: The Open Mobile Alliance (OMA) defines the term identity provider (IdP) as follows - An identity provider is “a special type of service provider […] that creates, maintains, and manages identity information for principals, and can provide […] assertions to other service providers within an authentication domain (or even a circle of trust).”
Another notion defines identity provider as “an agent that issues a digital identity [that] is acting on behalf of an issuing Party.” (Identity Gang)
The following definition of identity provider descends from WS-Federation @ IBM: “An identity provider is an entity that acts as an authentication service to end requestors and as data origin authentication service to service providers […]. Identity providers are trusted (logical) 3rd parties which need to be trusted both by the requestor […] and the service provider which may grant access to valuable resources and information based upon the integrity of the identity information provided by the identity provider.”
The Identity Provider is part of the Identity Management infrastructure.
  • Impact. The adverse effect resulting from a successful threat exercise of vulnerability. Can be described in terms of loss or degradation of any, or a combination of any, of the following three security goals: integrity, availability, and confidentiality.
  • Partial identity: a partial identity is a set of attributes of a user. Thus, an identity is composed of all attributes of a user, a partial identity is a subset of a user's identity. Typically, a user is known to another party only as a partial identity. A partial identity can have a unique identifier. The latter is a strong identifier if it is allows for a strong authentication of the user (holder) of the partial identity, such a cryptographic "identification" protocol
  • Privacy: Dictionary definitions of privacy refer to "the quality or state of being apart from company or observation, seclusion [...] freedom from unauthorized intrusion" (Merriam-Webster online). In the online world, we rely on a pragmatic definition of privacy, saying that privacy is the state of being free from certain privacy threats.
  • Privacy threats. The fundamental privacy threats are: traceability (the digital traces left during transactions), linkability (profile accumulation based on the digital traces), loss of control (over personal data) and identity theft (impersonation).
  • Risk analysis. The process of identifying security risks, determining their magnitude, and identifying areas needing safeguards. An analysis of an organization's information resources, its existing controls, and its remaining organizational and MIS vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage
  • Security monitoring. Usage of tools to prevent and detect compliance defaults, security events and malicious actions taken by subjects suspected of misusing the information system.
  • Service impact analysis. An analysis of a service’s requirements, processes, and interdependencies used to characterize information system contingency requirements and priorities in the event of a significant disruption.
  • Single sign-on: is “From a Principal’s perspective, single sign-on encompasses the capability to authenticate with some system entity—[…] an Identity Provider - and have that authentication honored by other system entities, [termed] Service Providers […]. Note that upon authenticating with an Identity Provider, the Identity Provider typically establishes and maintains some notion of local session state between itself and the Principal’s user agent. Service Providers may also maintain their own distinct local session state with a Principal’s user agent.” Liberty Alliance Project (LAP)
  • S&D: Security and Dependability
  • Threat. An event, process, activity being perpetuated by one or more threat agents, which, when realized, has an adverse effect on organization assets, resulting in losses (service delays or denials, disclosure of sensitive information, undesired patch of programs or data, reputation...)
  • USDL and USDL-Sec: The Unified Service Description Language (USDL) is a platform-neutral language for describing services. The security extension of this language is going to be developed FI-WARE project.
  • Vulnerability. A weakness or finding that is non-compliant, non-adherence to a requirement, a specification or a standard, or unprotected area of an otherwise secure system, which leaves the system open to potential attack or other problem.
  • WADL. The Web Application Description Language is a machine-readable XML description of HTTP-based web applications used typically with REST web services.
  • WS-SecurityPolicy: It is an extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS.
  • The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.

Content Based Security Glossary

  • Broker: the component that generates keys to remove protection from data
  • Consumer: the component that removes protection from data
  • Content Based Security: the concept of protecting data and its metadata at its source and integrating access control in a managed way
  • Metadata: labels describing data content
  • Producer: the component that applies protection to data


  • CBS Content Based Security
  • JKS Java KeyStore
  • OGE Optional Generic Enabler
  • SSL Secure Sockets Layer
  • WAR Web Archive
Personal tools
Create a book