[Cryptography] trojans in the firmware

[grarpamp]

On Tue, Feb 24, 2015 at 10:48 AM, Kay Rydyger <kay.rydyger at yahoo.co.uk> wrote:
>
> The question was [... firmware spies]
> The answer is [...] to encrypt data.

No, reading bits from platters or the bus is a partial analysis of
the whole firmware question. It's already been suggested in links
how firmware can hook the users unencrypted boot binaries through
to the users kernel. For that matter, a modified boot chain could
be stored in the service area.

A user would have to use SecureBoot, TPM, IOMMU, TXT, GELI and
perhaps other things, all of them properly, having no holes, together,
right now, at least three of which they are unlikely to have
ubiquitous access to until a couple hardware generations or personal
refresh cycles into the future. An ideal full solution for which
is yet to come. Not to mention needing to install it all cleanly
(from BTW, an install image which has no reproducible build and no
cryptographic chain back to the insecure unsigned source repo
anyways).

But yeah, let's talk circular instead of about possible actually
coding defense in depth such as maybe blocking the most common
easiest path a malicious opcode will likely take to irrepairably
infect clean hardware in the first place... through the drivers ...

> There is no threat to freebsd

... because at least Unix is said to be immune to threat...

http://www.freebsd.org/security/advisories.html
http://www.openbsd.org/errata56.html
http://web.nvd.nist.gov/view/vuln/search-results?query=linux+kernel&search_type=last3years&cves=on

> Weaknesses of this measure are remote and highly costly for the
> attacker. If one is such a person of interest

It's already been talked how this tech will be integrated into
everyday run of the mill malware. And how users will be subject to
infected drives via second purchase, inheritance (both from other
people and from other operating systems), use of hosting services,
trading, booting CD's, etc. Persistant malware in users boot chains
is nasty, users don't have to be of interest or be targeted, the
code doesn't care, grandma's surfbox could get it.


Please learn to email... trim the original to the minimum needed for
context, reply inline below, and stop copying 400 line digests with
meaningless digest subject lines out to everyone on the list.



On whenever, someone else wrote:
> Since the chip holding the firmware has
> leads through which it is loaded with the firmware,
> is it not possible to disable or burn (with laser) or cut
> just the leads through which the chip is WRITTEN to
> (in order to re-program it)?

Depends on the design. The hacking links or docs from the
drive/chip vendors would be more helpful there.