[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [P1619-3] OASIS EKMI Article in InformationWeek
I believe we will continue to disagree, Laszlo. Your comments reflect
a tactical view of data-security, while my focus is strategic. (While
data-protection is a strategic issue for companies, there are tactical
and strategic ways to address the problem that optimizes TCO over the
long-term).
I do not believe users will have the luxury of turning off encryption
on any device within the next 5-7 years (thanks to the inadequacy of
network-based security). Not only will government regulations around
the globe build on top of SB-1386, PIPEDA, EU Directive, RIPA, etc. to
stem the tide of breached-data, but companies will enforce encryption
to limit their external liabilities, and as a pre-requisite to comply
with their insurance policy requirements.
I do not believe that any of the limitations in today's technology
or environment will hamper encryption within applications. On the
contrary, the are hastening the adoption. Here are a few data-points
for my belief:
1) A 4-core 64-bit computer costs under $600 (I bought one 4 weeks ago
at a local computer store). 8- and 16-core chips have already been
promised by AMD/Intel for 2009, while 32-core CPUs are probably in
the wings for 2010;
2) I cannot find a reference, but I have been told of one of the 2 chip
manufacturers (AMD/Intel) having integrated crypto capabilities into
the main CPU, thus making it an HSM. Combine this "CPU-based HSM"
with the capabilities of multi-core CPUs and you have machines with
unprecedented crypto processing power. AMD has taken the GPU through
its full evolution and is already promising integrated CPU/GPU chips
this year; the same evolution cycle will occur with the crypto
processor, except faster than the CPU/GPU integration, IMO;
3) ISVs have already started modifying applications to encrypt sensitive
data within the application. Take a look at PABP and what ISVs have
to do to get their applications PABP-certified. While PABP applies
only to payment applications, the wisdom of those practices (and the
"free" security of the stack under the application) will not go
unnoticed by risk-managers, corporate developers and non-payment
application ISVs;
4) Just as the primary-key is an integral part of an object's schema,
the "global key-identifier" will also become an inherent part of an
object's schema. There will be as much likelihood of losing this
"global key-identifier" as losing the primary-key of an object;
5) Take a look at the traffic on the Java JCE forum at java.sun.com
and the BouncyCastle forum to get a sense for how many developers
have already started modifying their applications to encrypt
sensitive data within the application.
6) Some developer tools are already starting to show up on SourceForge
to automatically encrypt data within the application, albeit with
proprietary key-management interfaces.
Since I do not claim to be a cryptography expert, our intent in the
OASIS TC is to distribute the EKMI specification to three different
cryptography forums on the internet and solicit comments within the
60-day public review period that OASIS requires (anticipated to start
in mid-July). All comments and responses will be publicly visible on
OASIS' website during this period.
I would encourage you to document your concerns publicly when that
review period begins - you can do it as an individual if you choose
not to use your company affiliation for documenting your concerns.
Thanks.
Arshad Noor
StrongAuth, Inc.
Laszlo Hars wrote:
>> data needs to be encrypted and decrypted only by the resources that
> actually use data - the applications - and not the resources that store or
> transport it.
>
> This is where we disagree. The application does not have control over what
> happens to its data, when it is in transit or in storage. Of course, it can
> encrypt each piece of the data at the best security known, each with a
> different key, with a different random IV, but it is horribly ineffective.
> The application needs to get/store a large number of keys in key servers;
> the auxiliary data somewhere else and the encrypted data in yet another
> place. MS observed that if a byte takes more than 20 instructions to
> encrypt, users disable the crypto. Securely storing large amount of data
> under your paradigm is not realistic, and it will not be viable for quite a
> while.
>
> If the application does faster crypto instead of the best possible, there
> will be exploitable weaknesses in some cases. This is why the transport
> layer has to be and is optimized to its threat model, and the storage
> device to its threat model. Both work orders of magnitude faster than what
> you suggest.
>
> Also, under your paradigm data and key are bound together, forever. If you
> loose your key, the privacy is lost, too. If, however, the encryption is
> done at the disk drive, any authorized entity can change the key as often
> as necessary, so they can mitigate the lost key problems (until the
> attacker finds all data encrypted with the lost key). In this sense, your
> security is also weaker.
>
>
>
>
> Arshad Noor
> <arshad.noor@STRO
> NGAUTH.COM> To
> No Phone Info P1619-3@LISTSERV.IEEE.ORG
> Available cc
>
> Subject
> 07/02/2008 07:25 Re: [P1619-3] OASIS EKMI Article in
> PM InformationWeek
>
>
> Please respond to
> Arshad Noor
> <arshad.noor@STRO
> NGAUTH.COM>
>
>
>
>
>
>
> Laszlo,
>
> The reason I keep saying that there is no *long-term* reason for
> encrypting data on the device (or even the wire) is because of
> my belief in the paradigm that data needs to be encrypted and
> decrypted only by the resources that actually use data - the
> applications - and not the resources that store or transport it.
>
> The primary reason we have so many problems with securing IT
> infrastructure today, is because, for the last 20 years, we've
> been focusing on securing the network as a proxy for securing
> applications and data. This is because network device vendors
> have sold IT the notion that protecting the perimeter was all
> that was required, and you could leave all your computer hosts,
> applications and data alone. Very seductive. Thousands of
> companies bought into the vision and now look where we are:
>
> - Those who have firewalls must, typically, have port 25 and
> port 80 open to do business - and guess what? The attackers
> use precisely those ports to compromise live systems;
>
> - Applications are weak and insecure - many developers are still
> trying to protect against x-site scripting and SQL-injection
> attacks on the internet. And now - are you ready? - we have
> XML-injection attacks already surfacing against the new breed
> of SOA-based applications because the security paradigm I'm
> talking about is still out of focus for most IT organizations;
>
> And the industry is now getting ready to sell IT shops the same
> bag of goods - that its OK to continue ignoring the application
> and data - the stuff that really matters - as long as we secure
> the media and the wire.
>
> Application developers have gotten increasingly security-ignorant
> while attackers are getting increasingly sophisticated (one attack
> I read about even installs the attackers self-signed Root CA X509
> certificate on the target's PC and then redirects them to a cloned
> web-site of a financial institution with their own SSL certificate,
> thereby eliminating any security warnings about unknown CAs or
> sites while having the "lock" icon clearly ON! All this for a
> phishing attack. Most developers do not even understand how SSL
> works, let alone code something as sophisticated as this).
>
> If companies want to be secure, they need to stop focusing on the
> perimeter and devices and focus on the applications and data. This
> is the only long-term viable strategy, IMO.
>
> Once they've secured their applications and data, they can ignore
> the transport and media layers. A POS application encrypts CCN in
> the application, passes the ciphertext to the DB, which stores the
> ciphertext as a blob in the table on the storage media. Neither
> the wire, the DB nor the media care what the blob means; only the
> authorized application with the decryption key does.
>
> Securing an application isn't just about encrypting data. Its also
> about authenticating the resource that's trying to access the data;
> its about determining the authorization of the resource trying to
> access the data and finally, its also about determining the integrity
> of the data being accessed. An application needs to do all this.
> With the right combination of digital signatures and encryption
> all the threats you enumerate are addressed.
>
> You should download StrongKey and see what I'm talking about;
> everything I've described in this e-mail was implemented two years
> ago. This is the paradigm application developers need to move to
> if IT organizations want long-term security benefits at the lowest
> TCO. Just imagine, if all the applications developed over the last
> 20 years had followed this paradigm, we wouldn't even need firewalls
> today.
>
> Arshad Noor
> StrongAuth, Inc.
>
>
> Laszlo Hars wrote:
>> I understand that EKMI does not care where and how the keys are used. I
> had
>> issues with your other statements, like saying that there is no need for
>> encryption in the device level (P1619.0-2).
>>
>> You seem to agree that encryption in the transport layer is very
> different
>> from encryption in storage. In the later case, you cannot change the key
>> very often or use arbitrary IV's, without a large loss of storage
> capacity,
>> or the need of transferring a large amount of non-user data from a key
>> server, slowing the disks down. The need of encryption in the storage
>> devices remains for practical reasons: speed, capacity, security,
>> complexity...
>>
>>> Once the payload has been encrypted, then you can ignore threats to that
>> data at all other layers of the stack.
>>
>> This is putting your head in the sand. Such systems can still leak
> valuable
>> information: the equality of data blocks, the frequency of updates of
>> certain records, the location of system files, database records... We
> could
>> face malleability issues: messages could be replayed, data mixed and
>> matched, program data patched, documents falsified, etc. Our goal should
>> not be just to satisfy certain vaguely formulated laws, but to provide
>> (facilitate) comprehensive security.
>>
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]