Re: [P1619-3] OASIS EKMI Article in InformationWeek

[Arshad Noor <arshad.noor@xxxxxxxxxxxxxx>]

EKMI does not make any distinctions about data-in-transit or data-
at-rest, Laszlo.  It merely manages keys based on centrally-defined
policies, and lets the policy dictate how the keys are to be used.

However, by encrypting a Credit Card Number, a Medical record, or
a Tax-record with an SSN within the application, the keepers of IT
security do not have to worry about threats either to data-in-transit
or data-at-rest, because once the data leaves the application layer,
it is already encrypted.

This is the same reason why SKSML works as securely over HTTP and
does not care about SSL, TLS, IPSec or any other transport-level
security.  It is also the reason why cached keys on the client are
as secure as they are on the SKMS server or on the wire.  Once the
payload has been encrypted, then you can ignore threats to that data
at all other layers of the stack.

There is no reason to worry about traffic analysis with data encrypted
with keys delivered through SKSML; Security Officers can choose to
define a KeyUsePolicy that requires a completely new encryption key
for each transaction, if desired.  Or merely, generate a new IV for
each new transaction while using the same key for the hour, day, week,
etc.  The is significant flexibility within an SKMS.

I don't deny that a key within the application is at risk from all
of the threats you describe.  For those people who are paranoid
enough, they are going to be using a cryptographic module to do the
operation, in any case (inside a TPM, smartcard or HSM).  So, the
problem is mitigated, once again even with data-in-use.

Arshad Noor
StrongAuth, Inc.

Laszlo.Hars@xxxxxxxxxxx wrote:
> > It is my belief that once ISVs and customers recognize this problem,
> > they will start modifying their applications to encrypt data at the
> > application layer.  Once we're past the tipping-point on that, there
> > will be little need for duplicating encryption on storage-devices.
>
> It is not that easy. Protecting data in transit has very different
> constraint, security requirements, threat models, attack scenarios than
> protecting data at rest on the storage medium. If you design a single
> encryption scheme for both, it could be very inefficient in the storage
> device: e.g. we might need to store a random IV at every sector, like in
> tapes. At small disk sectors this would cause a considerable waste of
> capacity, therefore there is often a “need for duplicating encryption on
> storage-devices”.
>
> Another issue of the many: To prevent traffic analysis attacks, the storage
> address (LBA) has to be encrypted, too, dependent on changing IV’s. This
> presents difficulties at disk arrays, where data cannot be routed to the
> destination drive without knowing the encryption key, consequently all
> drives have to see all the data, and decrypt at least part of the data to
> see if it was sent to them.
>
> There are also security concerns. An encrypting disk drive never reveals
> its key, it is not stored permanently anywhere. This gives us information
> theoretical security: a lost or stolen disk drive does not contain the
> information necessary for decrypting its data. However, if the encryption
> is performed in the application layer, the key has to be known and
> constantly in use there, making it vulnerable to viruses, root kits, bus
> analyzers, software bugs, etc.
>
> The key delivered to the drive by P1619.3 or OASIS or any other key
> management scheme, must not be the encryption key itself, but an
> authentication key, which is part of the input of a one way key derivation
> function.