Military Communications and Information Technology: A Trusted ...

448 Military Communications and Information Technology...
Attribution in the context of security policy breaks requires keeping a log
of the changes made to the permissions. A security policy break translates into
unauthorized insertion, removal or modification of security metadata. This can include
(but are not limited to): Insertion of additional block keys (to leak information);
Insertion of additional public keys (to enable modification); Downgrading
the (MLS-related) classification labels; Changing or adding administrator information
and certification.
To enforce attribution and rollback of the security metadata, we introduce
per-element metadata-history to the schema. Rollback cannot naturally be fully
realized, if the whole history-information is deleted from the document, but this
is left for the availability-function of the Storage (cloud), and outside the scope
of the schema.
The metadata history is always signed as a whole by the Filter itself. This is because
of the principle of separation of duties: roles administering security policy
should not also track the changes made by themselves.
Metadata history contains copies of the security metadata appended with
a timestamp and identity of the original signatory of that particular instance
(an ADMIN-User or the Owner).
The ADMIN-user or (originally) the Owner is responsible for creating and
changing the security policy reflected in the security metadata. The principle
in the modification is to create a new copy based on the old metadata and move
the old copy to the history. The responsibility for the metadata is reflected in a subelement
of the security metadata structure, containing the list of the administrator
roles, and finally a signature by one of these administrators. Administrator role
information must include a PKMA-dependent certification from the Owner.
E. Design principles: MLS considerations
Multi-level security is considered here from the document perspective only.
The CBIS-schema presented here does not account for the User clearance – if IBCbased
PKMA is used, the user clearance can be encoded in the encrypted block
key, but for other PKMAs this is left for the application. (Which is why we recommend
using IBC to achieve a fuller cryptographic enforcement of the security levels
than just key management.)
The security label exists in the document metadata. Its correctness is enforced
by an ADMIN-user’s signature (together with a delegation certification from
the Owner) and it is bound to the content by the compound signatures of the content
and metadata. (Signed by the Filter, as this is an administrative function).
The security label presents a performance issue in the XML-document tree
hierarchy, if the structure is very fine-grained ([12, 14]): in order to establish
if a user has clearance to the lowest levels of the hierarchy, all of the nodes need
to be traversed. To enable more efficient processing, two strategies are possible: