On Tue, 9 Sep 2003, Sean Smith wrote:
>>
>> >How can you verify that a remote computer is the "real thing, doing
>> >the right thing?"
>>
>> You cannot.
>
>Using a high-end secure coprocessor (such as the 4758, but not
>with a flawed application) will raise the threshold for the adversary
>significantly.
The problem with this is Moore's law. By the time your high-end
coprocessor is widely adopted, most of the actual units out there will
no longer be high-end. And the kid who has the latest hardware will
always be able to emulate an older secure coprocessor in realtime, the
same way they used to use hacked printer drivers to simulate the
presence of hardware dongles on the parallel port. So this doesn't
work unless you put a "speed limit" on CPU's, and that's ridiculous.
>No, there are no absolutes. But there are things you can do.
Yes. Protocol designers have been explaining how to do them for
decades. There is usually a protocol that allows untrusted machines
to only have data suited for handling by untrusted machines, while
still providing the appropriate benefits.
There are things you can't do that way, of course; a machine cannot
display information to a human that it does not have. But a
remote-and-therefore-untrusted machine is in front of a
remote-and-therefore-untrusted human, and therefore ought not do such
a thing anyway.
Designing applications that use protocols to achieve design goals
without ever transmitting information that an untrusted machine ought
not have is hard. But it is possible, and until it's done we're going
to see a parade of cracked applications and hacked hardware destroying
every business plan that's built on it and every life that depends on
it. Depending on a solution that lets "remote but trusted" hardware
handle information that the remote machine shouldn't have in the first
place is an invitation to be hacked, and an excuse to avoid the hard
work of designing proper protocols.
>> The correct security approach is to never give a remote machine
>> any data that you don't want an untrusted machine to have.
>
>So you never buy anything online, or use a medical facility
>that uses computers?
Online credit-card purchases are ten percent fraudulent by volume.
Crypto is widely deployed for credit-card purchases, but stemming
fraud seems to be like trying to dig a hole in water. Points made
here recently about who has a motive to stop fraud seem applicable.
And, significantly, much of this fraud is done by people who manage to
crack the merchants' databases of credit card numbers and accounts
which are kept in cleartext. I don't think any crypto infrastructure
is going to stop "personal" card fraud by someone who's got your card
out of your wallet. Boyfriends, Girlfriends, roommates, and siblings
commit a lot of fraud on each other. But a better protocol design
should at least put credit card numbers in merchant databases out of
reach of crackers - by never letting the merchants get them in
cleartext.
A merchant should wind up with a unique "purchase code" - a blob from
which the bank (and no one else) ought to be able to tell the payee,
the amount, the source of funds, and the date of the transaction.
This is fairly simple to do with asymmetric encryption where the bank
has a published key. A merchant should NOT wind up with a cleartext
credit card number for an online purchase. Someone hacking the
merchant's database should NOT wind up with information that can be
"replayed" to commit frauds. This isn't a matter of transmitting
priveleged (sensitive) information to a "remote but trusted" machine;
this is a matter of finding an appropriate (non-sensitive) form of
information that a remote machine can be trusted with. No special
hardware is required, it's just a matter of using the appropriate
protocol.
Frankly I don't know enough about how medical records are handled to
say much about them - I couldn't even make a good assessment of the
operational requirements. But the information has huge economic value
as well as huge personal privacy value. Its inappropriate disclosure
or misuse can destroy lives and livelihoods. It ought to be
considered, and protected, as a target for theft.
Bear
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
