On Sat, Feb 21, 2015 at 8:41 AM, Kay Rydyger <kay.rydyger at yahoo.co.uk>:
Please do not quote 200 lines of text just to insert your ten.
And if using the digest, use the original subject line. Else
it's lazy bad form at the expense of other readers of the list.
>> > Alfred Hegemeier <molybdanstahl-hh at yahoo.co.uk> saith:
>> > just encrypt the whole hard drive with Geli.
>>
>> GELI works under your control for what you store on the
>> drive, and you can even enable the AES encryption feature
>> of the drive itself as a no cost to performance extra freebie
>> underneath that. However since the raw device interface is still
>> accessible, neither of them do anything to block firmware
>> updates.
> what has blocking firmware updates to do with
> firmware being able to read the data passing
> through the controller ?
Reread the entire thread and all the linked materials.
If your drive is clean and you kernel block the malicious
firmware update command, the exploit fails and your drive
remains clean. If you don't block it, then your drive gets
rooted and then yes, there's nothing you can do after that.
And since users don't have JTAG gear/skills and device
vendors usually never publish a firmware update anyway,
you can't verify or securely reflash even if you did discover
it got rooted. Thus you now own a worthless brick with a
warranty that won't be honored.
> That encryption is a good line of defense, you can
> read here:
> https://www.ibr.cs.tu-bs.de/users/kurmus/papers/acsac13.pdf
> in section 4.1.
No hardware and software disk encryption themselves don't
prevent installation of the firmware, nor help much afterwards
given the current as yet non-ideal state of the entire system
protection/crypto ecosystem. The MBR, boot, loader and whatever
other early stages, are not encrypted or signed... malicious
firmware can exploit that. It could also use DMA to read/write
RAM to get your FDE keys and so on. Even SecureBoot with
FDE doesn't help there. It's all caveated in the doc.
To be more secure you need to disallow the malicious firmware
update from taking place to begin with. The standard interface
for that is through the /dev device provided by the disk driver over
the bus subsystem. Block/filter out all non-production opcodes
from those interfaces and and it becomes more work for kids to
exploit. Add that to other defenses in depth and you're better off.
Long term, you should demand the vendors include a $0.10
hardware read-only update jumper and a signed authority root
anchored in the mask ROM.
You should demand the t10/t11/t13/serialata standards bodies
include a readout command for firmware verification and backup.
For that matter, you should demand vendors include another
jumper for pointing to your own installable ROM space in flash
(or via pin header) and to also open up their specs so you don't
have to use their literally stupid and broken firmware blobs [1].
How many tens of thousands of users strong are you BSD?
How many tens of thousands of users strong is Linux?
Yet all of you combined can't seem to place even two calls/mails
per month to each vendor asking for these things... shame. You
can and should be overloading their switchboards... they'd drop
to their knees before your armies in a week.
[1] Vendor code is generally buggy crap quality, quite often
highly guarded just to save embarassement there, to dodge
responsibility for making fixes by saying "what bugs, where",
and to speed up obsolesense.