[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encryption and ERS
----- Original Message -----
From: "Aljosa Jerman Blazic" <aljosa@xxxxxxxxx>
Sent: Friday, October 19, 2007 9:14 AM
Subject: RE: Encryption and ERS
as it is said in the paragraph before:
"Only encryption methods should be used that make it possible
to prove that archive-timestamped encrypted data objects
unambiguously represent unencrypted data objects.
All data necessary to prove unambiguous representation should
be included in the archived data objects."
Indeed, but the next paragraph states: "...additional data necessary to
re-encrypt data objects should be inserted into the evidence record by the
client..." meaning that data is inserted in an evidence record by a client
after it is created. Or am I missing something...?
The problem is in editing the data object to create a derivative of the
original IP and representing that this is the original IP. Its not... its
IP that was reencapsulated or chaned cryptographically inside of an LTANS
carrier. What needs to happen is restamped images need to be 'and'ed into
the envelope as an additional instance of the document. That is to say there
are both legal and business reasons for maintaining the document's signature
status, and to do that a chain of custody as to the changes that it
underwent also have to be included with the newly updated evedntiary content
Note, that this implies a 1:n - Function (1 unencrypted
message may represented by n encrypted messages) not a 1:1 - Function.
In practice some encryption functions - e.g. used in CMS -
use additional start parameters (random numbers) - in order
to avoid some kind of attacks knowing plaintexts.
I am aware of the additional parameters, however 1 encrypted message may
result in n unencrypted messages when different cryptographic material is
used. And this is where I see the problem as there is no hard proof that
1:1 transformation is provided for ERS checking. If a client is in control
of such information (crypto material) then there is hard to set a proper
level of trust as the (encrypted) data submitted for ERS generation may
actually originate from n different data sets... In theory at least.
Therfore these additional Parameters may be necessary to
reconstruct the (archive-)timestamped encrypted message, if
it was deleted.
Nethertheless, there is no security problem, if these
parameters are not time-stamped - because of the requirement,
that the encrypted message should unambiguous represent the
Hmmm, I understood that by inserting some of the information into the ERS
this "unambiguousity" is achieved...
[mailto:owner-ietf-ltans@xxxxxxxxxxxx] Im Auftrag von Aljosa
Gesendet: Freitag, 19. Oktober 2007 16:01
Betreff: Encryption and ERS
I am working on the next version of XMLERS and by studying
the last ERS spec (RFC actually), I stumbled over encryption part:
"When a relying party uses an evidence record to prove the
existence of encrypted data objects, it may be desirable for
clients to only store the unencrypted data objects and to delete
the encrypted copy. In order to use the evidence
record, it must
then be possible to unambiguously re-encrypt the
to get exactly the data that was originally archived.
additional data necessary to re-encrypt data objects should be
inserted into the evidence record by the client, i.e., the LTA
never sees these values."
This approach foresees the inclusion of, correct me if I am
wrong, data necessary to re-encrypt data by a client to
validate ERS generated. Now the question here is, how can
such information be trusted from a client?
It somehow breaks the point of ERS. It is true that LTA never
sees such data but this, IMO, does not affect the
confidentiality issues and it even does not make sense, as
the crypto material used for encryption is usually public... Or?
Also, there is a typo on page 19: instead of "ha(1), ha(2),
ha(3) are as defined in step 4 above" it should be "ha(1),
ha(2), ha(3) are as defined in step 3 above"
tel: +386 1 4773505
fax: +386 1 4773911