Military Communications and Information Technology: A Trusted ...

Chapter 4: Information Assurance & Cyber Defence
447
The Filter signs parts of the document security metadata (History-related).
As the Filter is only semi-trusted, and ADMIN-users may have conflicts of interests,
different public keys need a validity certification from the Owner.
The Filter validity certification is required irrespective of the PKMA. We assume
for simplicity that the correspondence between Owner and a document is oneto-many
(instead of many-to-many). Thus the validity certification can be placed
in the per-document metadata element. Furthermore, the schema doesn’t specify
the form of the certification – it could be a PKI certificate, IBC-based delegation (e.g.
with a public key of the type “Owner X grants admin privileges to
Filter Y”, which is verifiable with the Owner X public parameters and the claimed
string only), or something else, as long as it contains sufficient cryptographic strength.
In order to separate the administration and content, some cryptographic
conventions need to be observed:
• The need to separate non-repudiation and basic integrity signatures
is PKMA-dependent, so the number of signatures is left open here, and
the types of signatures are listed as widely as needed.
• Layered encryption (super-encryption, encrypting already enciphered content)
is not used. Opening administrative metadata would require additional
layers of filters and/or key management. In [12] and [11] super-encryption
is defined – the purpose here could be embedding other documents or hiding
the access control information – but we leave it out here for simplicity.
D. Design principles: versioning
The main document is assumed to be modifiable. There are two types of modification
possibilities: content modification and permission type modification.
In each case, the CAC paradigm entails that since the actual modifications cannot
be prevented (only detected), there should be a possibility of rollback and attribution
(finding the perpetrator).
Rollback requires versioning and storage of the previous versions. Content
versioning is considered to be outside the scope of this paper – it can be done
by creating a separate document per committed modification and transferring
the versioning burden to the Storage (as it should be optimized for availability).
Per-element versioning does affect the CBIS schema itself, and this is considered
more of a document management than a security issue. Per-element versioning
should bind the content signature together with the content – thus we do not consider
content signature versioning either here.
Attribution has two facets: illegal modifiers of content and security policy.
If content is modified meaningfully, it implies than legal keys of some user are
used. This in turn can be traced back to the user identity by comparing different
versions and signature information. Thus content modification attribution is built
in to the signatures (enforcing non-repudiation) and versioning.