On Sat, 22 Jul 2000, Khimenko Victor wrote:
>>>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
>[SNIP]
>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.
Yep.
> 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.
Agreed. The key being that it is implemented properly, and that
proper security guru's were involved in the process, not some MS
Visual Basic programmer.
>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.
The fear being that a fair number of companies would likely
downplay the security issue and take a cut corner approach, or
mis-implement something that THEY thought was secure, but which
was not.
I get a laugh for example from the console game systems. Every
one that comes out claims that their games can not be cracked
because of some new super crypto thing. 3 days later some hacker
has cracked it and exposed all details... ;o)
>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.
Exactly. That is the only way IMHO.
>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.
Sory, what I meant by "filter" is that the drive "filters" the
update sent to it by ensureing it is a true update via encrypted
sig or whatnot. If the sig doesn't match, the drive filters it
to the go away pile.
>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.
Sorry, my choice of the word "filter" was bad, its not what I
meant.
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- 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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:19 EST