lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Butting in.. (Was: scsi-destroyer.c to come...)
In <Pine.LNX.4.21.0007221447050.21586-100000@asdf.capslock.lan> Mike A. Harris (mharris@meteng.on.ca) wrote:
MH> On Sat, 22 Jul 2000, Khimenko Victor wrote:

>>> In this mainly-IDE-thread there have been at least two facts stated (or
>>> discussed) and I've got some comments on them. (Woohoo!)
>>
>>> 1. It is possible to write software that will damage hardware.
>>
>>[Explanation how wrong firmware uploading process can screw you hardware skipped]
>>
>>This is all right. But you can SIGN firmware blob and hardware will just
>>refuse to accept update with bad sign. How much it cost ? I have SmartCard
>>from Oberthur here where such protection is implemented. This card cost less
>>then 3$. Complete with CPU, memory, built-in DES (used for signature checking
>>in TripleDES mode) and so on. Since IDE/ATAPI drive (or you modem) ALREADY have
>>CPU, memory it'll add perhaps few CENTS to cost and will give you almost 100%
>>protection. Do we really need to tolerate hardware with ability to destroy it
>>with few simple commands just to save few CENTS per computer ?

MH> That would definitely be better than what we have now, however I
MH> would still question the true security of it. DVD was cracked.

Devil is in details :-) DVD was cracked just since good cryptography was used
wrong way. DVD approarch was flawed by two reasons:
1. Key is stored in software. No matter how deep it's obscured if it's in
PC memory it CAN BE found - sooner or later. In proposed case key is NEVER
exposed for PC: all is done in HDD itself.
2. ONE key was used for LOTS AND LOTS of videos. In case of firmware upgrade
you can use different key for each group of drives (100-1000). Since each
TripleDES signature is just 16 bytes you can attach 10000 signatures (and thus
1'000'000-10'000'000) and still add only 160K to firmware upgrade size. Then
even if you'll crack one key you'll still can corrupt only 100-1000 systems
in worst case. And even this is problematic and does not worth trouble if
this 100-1000 drives are in different parties (that is: you are NOT using
first key for first 1000 drives, second one for next 1000 drives and so on;
instead you are using first key for first drive, second key for second drive,
..., 10000 key for 10000 drive and then repeat from the beginning).

Yes, crypto is not silver bullet. Still it's VERY hard to break if used right.

MH> Granted, the usefullness of it is several orders of magnitude
MH> higher than someone cracking a firmware key, but if implemented
MH> poorly, it could happen.

Oh, year. Of course. Still it's not THAT hard to implement properly.

MH> The thing is there is no way of really knowing if it is implemented well.

Pubish the whole procedure BEFORE creating hardware to implement it. Wait and
see responces from crypto-analysts. If they all said "it's ok to do" go ahead.

MH> I guess I'd rather know it does try to filter the firmware updates, and
MH> trust it though than have nothing and have easily damageable hardware.

You can not filter them. Not if you have raw I/O access. And if you DO NOT
need raw I/O access then better to disable it completely then to try fitler it.
This stuff is not needed in running system anyway so just configure all your
IDE drives properly and remove raw I/O access from system.

If something is REALLY needed without raw I/O access then provide IOCTLs to do
JUST WHAT IS NEEDED, do not try to filter our raw data.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.068 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site