Cryptographically Computing Per-User Unique Identifiers That Cannot Be Mapped To The Underlying ECM System's ID
Publication Date: 2014-Jun-19
The IP.com Prior Art Database
AbstractDisclosed is a method to provide an additional layer of security for a document in a high security Enterprise Content Management (ECM) system. With this method, no user, other than the one who retrieves a given document, can identify the document by reading the associated system identifier.
Page 01 of 3
Cryptographically Computing Per -
-User Unique Identifiers That Cannot Be Mapped To
User Unique Identifiers That Cannot Be Mapped To
The Underlying ECM System '
For Enterprise Content Management (ECM) systems in very high security environments, unauthorized disclosure of the mere existence (native identifier) of a document can constitute data leakage. Often the ECM system identifiers (IDs) that are used to reference documents (i.e. links to documents inside of other documents) can leak the identity of the source document even if the person seeing the ID never has access.
A method is herein disclosed to provide an additional layer of security in these cases, wherein no user, other than the one who retrieved a given document, can identify the document by reading the associated ID. This level of security prevents the identification of the secure document by an unauthorized user (even one who has access to the document), unless that party is prepared for a massive computational cost.
In an example embodiment of the present invention, in a highly restricted document in an ECM system, only certain individuals are permitted to know of the existence of a document. For this example document, the internal/native ID is 11111111-1111-1111-1111 (referred to from here out as IDnative).
Users, U1 and U2, have authority to retrieve the document. U3 does not. No users of the system know IDnative. U1 performs a search for this document and sees the ID as: 'asdfkhwe3407@$$@@#$32327sdrjkdrASDFASERselrhe44724d7ASDFARE$3423rwe 444' (referred to from here out as ID1).
If U1 tries to retrieve this document by ID1, it is successful.
U2 performs a search for the document and sees that ID as: 'vnmswkrjf^@&*(*)*@#$%&(DTISGJE%LDDF#2348vnxlkdir4724&*($@#++_--=' (entirely different from the id that U1 sees, and referred to as ID2). If U2 tries to retrieve ID2, it is successful.
If U2 tries to retrieve ID1, it fails and the system can audit log that U2 tried to retrieve an ID that was generated for U1.
If U3 tries to retrieve ID1 or ID2, it fails and the system can log that U3 tried to use an ID from another user, and then log the source user of this leak.
In another example of the disclosed method, U1 authors a personal document (D_lower_sec) with lower security such that U3 has rights to this document. In this document, U1 refers to ID1. If U3 reads this document and obtains ID1, it is useless. The users can neither retrieve it (this is already enforced by the ECM system) nor obtain IDnative to identify to which document it refers. If U3 manages to steal superuser credentials (credentials that have rights to view IDnative), not enough information is there to be of any use. Tying to retrieve ID1 with super-user credentials
Page 02 of 3
would fail and log that an ID generated for U1 had been compromised.
The following provide additional details regarding the above described method:
Let IDnative be the native id of a document that is marked to be...