[Cryptography] Confidential Document Management, the right name or weaselly marketing?

[Phillip Hallam-Baker]

So, I am working on a document to describe the use of Mesh/Recrypt, a
messaging infrastructure built on the Mathematical Mesh that uses Proxy
Re-encryption to allow control of access to confidential documents.

Before getting too far, yes, there is a patent on this obvious application
of Proxy Re-encryption but not one that is too much of a concern as it is
most unlikely we could build anything before it expires (18 months).


One of the biggest problems I see is that the use of cryptography in this
field has been mostly focused on the problem of 'Digital Rights Management'
by which is meant control of copyright material. And that is an anathema to
many people.

The problems with cryptographic enforcement of copyright are obvious. The
more people you share information with, the more likely it is that the data
will leak. In the copyright enforcement model the customer is the
adversary. The requirement is to design a system consisting of hardware and
software that allows information to be given to an attacker in a form that
allows them to use it but not to pass the data on to another party.

While it is certainly possible to design a DRM scheme that mitigates
extraction of controlled content, all DRM systems are inevitably imperfect
as DRM is a break once, run anywhere problem. The attacker only has to
crack one Blu Ray player or set top box or monitor to gain access to the
plaintext copy of The Force Awakens and they have a property they can
bootleg for millions.

Yes, I do get that. But that is not the problem I want to solve. Nor do I
believe that it is important to solve the weaker problem of 'Content Rights
Management' in which we attempt to develop an infrastructure that allows a
small, closed set of users to read content without the ability to pass it
on.


In the typical enterprise (e.g. the NSA) there are large quantities of data
that are confidential for some reason (e.g. the powerpoint slides
describing PRISM) that must be stored on enterprise controlled servers
managed by people who do not have a need to know the contents of the
material they manage (e.g. 29 year old contractors).

If such an enterprise was security conscious and technically capable, it
would surely want to restrict the distribution of such confidential
material to exactly the set of people with a need to know. And this is
where proxy Re-Encryption is such a powerful tool.

The encryption key of a proxy re-encryption keyset corresponds to a
security label (e.g. prism at nsa.gov)

The decryption key of of a proxy re-encryption keyset corresponds to the
right to administer that security label (e.g. Col. Mustard)

Recryption keys in a proxy re-encryption keyset are generated by the
administrator and correspond to a grant of read access to the material
(e.g. Cpt Prang).


I believe that a security infrastructure that has the ability to manage
confidential data according to this approach offers a great deal of
security value to the typical enterprise even if the ultimately insoluble
problem of content forwarding is not addressed at all.

Restricting the distribution of the documents to Cpt Prang and others with
a need to know is the first and most important task. Preventing Cpt Prang
from forwarding the document to North Korea is a separate task and one that
we should not expect a perfect solution to.

So what I need is a new name that dispenses with the onward distribution
baggage that the DRM and CRM terms focus on. My objective is to control the
distribution of confidential documents so that these are secured end-to-end
and are not visible to administrators of servers, anyone who might find a
thumb drive or buy a hard drive off EBay.


So the names I am considering are:

Confidential Document Control
Confidential Document Management
Confidential Content Control
Confidential Content Management

Or is trying to separate this problem from the established CRM problem too
weaselly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160818/659bd5a4/attachment.html>