31–40 of 96 posts
> Because Linux caches the shadow file (like all files recently accessed), I have to generate a lot of disk activity for the file to be 'pushed out' of the cache http://linux-mm.org/Drop_Caches $ echo 3 > /proc/sys/vm/drop_caches or as non-root $ echo 3 | sudo tee /proc/sys/vm/drop_caches
something I hadn't really considered about hard disk encryption, before reading this, is how it could protect against compromised disk controllers. if the OS encrypts the data stored on the disk, it would be a lot harder (perhaps, with the right composition, impossible) for a malicious disk controller to insert/change/modify important data (like code, or password files) stored on the computer. we think of the system…
Earlier quoted context omitted.
The knee jerk reaction to secure boot-anything from the technical community has been generally "No!", "It's a trap" etc.
The knee jerk reaction is not to secure boot but to who has the ability to set the keys. The technical community likes to be in control of that.
E.g. the FOSS community wasn't a fan of only-trusted-secure-boot when it was microsoft holding the keys and the source and releasing neither.
God says... C:\TAD\Text\WEALTH.TXT
e very circumstance which ought certainly to alleviate it, the temptation to commit the crime. {See Sketches of the History of Man page 474, and Seq.} Fourthly, by subjecting the people to the frequent visits and the odious examination of the tax-gatherers, it may expose them to much unnecessary trouble, vexation, and oppression; and though vexation is not, strictly speaking, expense, it is certainly equivalent to the expense at which every man would be willing to redeem himself from it. It is in so
----
God can kill with a word.
something I hadn't really considered about hard disk encryption, before reading this, is how it could protect against compromised disk controllers. if the OS encrypts the data stored on the disk, it would be a lot harder (perhaps, with the right composition, impossible) for a malicious disk controller to insert/change/modify important data (like code, or password files) stored on the computer. we think of the system…
Maybe I misunderstood, but didn't the harddrive have direct memory access (DMA)?
My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
Your typical motherboard's BIOS code is not signed. Your video card's BIOS is not signed. Your network's card firmware is not signed. Your optical disc drive's firmware is not signed. Etc. This threat vector exists with each of these devices. As always security is a trade-off. The threat vector of flashing a backdoored BIOS/firmware is irrelevant for 99% of the market: most people will never be targets of such highly…
Adding security to a system imposes costs on the use, maintenance, and support of those systems. Can you imagine the scale issues associated with maintaining PKI over the millions of devices deployed? How about hundreds of millions?
TPM is present in many, many laptops yet most IT departments leave it un-configured. Why? Because when you replace the hard drive and it changes the boot vector parameters, the machine will no longer boot and you have to work inside the auth mechanisms of the TPM infrastructure do to simple hard drive replacements. (nb: I'm not an IT guy so I might be a bit off here, but you get the gist)
So the reasons for NOT including security are pretty damn big compared to the risk. As security guys are fond of saying: "If I can get physical access to your machine, all bets are off." Keyloggers, evil maid BIOS, HID attacks, firmware attacks on peripherals, etc are all possible ways to compromise a device. If you're wondering how STUXNET got into an air-gapped security facility in Iran, I'd bet that a method like this was the prime candidate. That's how I'd do it.
Earlier quoted context omitted.
Your typical motherboard's BIOS code is not signed. Your video card's BIOS is not signed. Your network's card firmware is not signed. Your optical disc drive's firmware is not signed. Etc. This threat vector exists with each of these devices. As always security is a trade-off. The threat vector of flashing a backdoored BIOS/firmware is irrelevant for 99% of the market: most people will never be targets of such highly…
In Secure Boot environments, this is all untrue - all option ROMs are signed, and the firmware should only accept signed updates. That pushes the problem out to ancillary devices that we've traditionally thought of as safe, but this demonstrates that they really need to reconsider.
something I hadn't really considered about hard disk encryption, before reading this, is how it could protect against compromised disk controllers. if the OS encrypts the data stored on the disk, it would be a lot harder (perhaps, with the right composition, impossible) for a malicious disk controller to insert/change/modify important data (like code, or password files) stored on the computer. we think of the system…
The first hack read on hacker new I have seen for a long time.
My knee-jerk reaction was, why didn't WD sign the code and use on-chip fuses and a secure boot path to verify the code before transferring control to anything outside their boot ROM? (Many ARM-based systems-on-a-chip are capable of doing this). Adds cost, for one thing. But you can arrange for the unit to never run a byte of code (even one loaded from the platter) that didn't come from WD.
The knee jerk reaction to secure boot-anything from the technical community has been generally "No!", "It's a trap" etc.
Secure boot isn't a technical solution to a soft/firmware update problem. It's a control mechanism to solve a management problem. Crazy idea, don't put the interface that has access to firmware on the standard interface. Use its own interface and allow motherboard manufacturers to support it for enterprise/datacenter geared systems.