Military Communications and Information Technology: A Trusted ...

Chapter 4: Information Assurance & Cyber Defence
441
onstrator [15, 18] was aimed at the cryptographic solution of MLS. In CBIS, all
the information is encrypted and signed, protecting the confidentiality and integrity
of the document.
The original CBIS effort was, however, abandoned as too expensive, possibly
due to the constraints and difficulties in key management [1] and user authentication.
The concept was revived in (at least) the Finnish military [12], where a different
public-key management architecture (PKMA) was substituted for the PKI.
The PKMA substituted in [12] was called identity-based cryptography
(IBC, [6]). In IBC the identity itself acts as the public key, removing the need for
certificates, enabling natural hierarchies and delayed creation for the private key.
With IBC extensions, such as attribute-based encryption (ABE), it is possible to
encode access structures directly to the ciphertexts.
In the later CBIS concept, the actual content is endowed with different levels
of metadata that can be used to embed security related information to the document
itself, distributing the protection information from the reference monitor to
the data itself.
Adding metadata to the protected data blob implies the need to protect
the metadata as well, and thus further levels of metadata. An obvious framework
for dealing with intergrated data and metadata is eXtensible Markup Language
(XML) framework.
The work in [12] laid out several steps from moving traditional referencemonitor-based
access control to cryptographically enforced, MLS-capable access
control. These are depicted in Fig. 1.
Figure 1. Moving from traditional access control to CBIS ([12])
In Fig. 1, the steps are not wholly sequential: e.g. attribute-based cryptography
access control is trialled already as such ([17]), but it was deemed infeasible to leap
to mostly academic technologies straight away. As can be seen, there will be a change
of public-key cryptography paradigms, or key management architectures at some
point. This alone places restrictions on how the actual hierarchical data should be
structured, but it is also otherwise prudent to (functionally) separate content from
security, and cryptographic key management from the rest of security functions
as separate modules.