Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 22 Jul 2000 23:31:45 +0400 (MSD) | Subject | Re: 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/
| |