[OFF-TOPIC] Intel processor backdoors

[J.M. Porup]

I am working on a new novel with the working title THE MAN WITH THE ZERO-DAY EXPLOIT. I want it to be as realistic as possible, and to be plausible to security professionals.

Specifically I am interested in Intel hardware vulnerabilities, potential NSA backdoors, and so forth.

I've spent some time googling this, but not found much to go on. I have quite a few years of programming experience under my belt, but I never took a CS degree, and my hardware knowledge is scant.

Can anyone point me to a resource on hacking hardware, and how such a vulnerability could be detected by a non-state actor? (Think: Anonymous)

thanks
Jens

[Joanna Rutkowska]

Hi Jens,

You will find a lot about vulnerabilities in Intel TXT, VT-d, SMM/BIOS,
and other "hardware" (these days "processor", as least Intel's, contain
much more than just "CPU"), as well as some discussions on potential CPU
backdoors on my blog (years 2009-2011 mostly, some in 2008 and 2012).

And for some technical papers see:

http://www.invisiblethingslab.com/itl/Resources.html

You might also want to contact Luic Duflot and his team.

If you want specific links, please define your question more precisely.

Don't forget to mention that Qubes OS aims at solving many of the
problems related to h/w backdoors/vulns (except for those in processors).

Regards,
joanna.

[Vincent Penquerc'h]

On 11/08/14 00:32, J.M. Porup wrote:
> Specifically I am interested in Intel hardware vulnerabilities, potential NSA backdoors, and so forth.

For more "generic" discussion, comments by RobertT and Clive Robinson on
Schneier's blog a few months back are also interesting. I think most of
RobertT's posts were about hw subversion on the manufcturing process and
similar subjects, so searching for this name should get you a good haul.

[J.M. Porup]

Let me put it to you this way. You are the NSA. You can order Intel
to redesign their chips to be permanently backdoored. What do you
tell them to do?

Sabotage the RNG. OK. What else?

What would be the ultimate backdoor on your wishlist, that was
also hard to detect and plausibly deniable?

thanks
Jens

[Joanna Rutkowska]

Some thoughts:

http://theinvisiblethings.blogspot.com/2009/06/more-thoughts-on-cpu-backdoors.html

j.

[cprise]

I recently read an article about a researcher who can examine the logic
of certain microchips by slicing them into many layers, but I don't know
if its possible with complex CPUs yet. Unfortunately I can't find the
article, though googling 'reverse engineer microchips' brings up some
interesting pages.

If such internal auditing of Intel CPUs does become a reality, I imagine
that Intel would have to add backdoors in such a way that foul play
could be plausibly denied (e.g. they would have to look like
unintentional bugs).

[Pedro Martins]

Something recent:
Errata prompts Intel to disable TSX in Haswell, early Broadwell CPUs
http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus

from the text: "These first production Broadwell chips will also have
TSX disabled via microcode."

Something could be *enabled* via microcode, after a short stop at the
customs on the way to the target^Wcustomer...

--
Pedro Martins

[Steve Coleman]

On 08/12/14 16:49, cprise wrote:

> I recently read an article about a researcher who can examine the logic
> of certain microchips by slicing them into many layers, but I don't know
> if its possible with complex CPUs yet. Unfortunately I can't find the
> article, though googling 'reverse engineer microchips' brings up some
> interesting pages.

There was a company by the name flylogic.net (now part of IOactive.com)
that used to blog about reverse engineering silicon. Unfortunately that
blog was taken off line with that acquisition, but many papers are still
available. Just google "flylogic" and you will get many hits about this
reverse engineering of silicon.

They were not slicing per se, but rather chemically removing layers and
photographing each layer, one step at a time, then recomposing the
circuitry in software. In some cases they could even edit the silicon to
change certain properties of the circuit.

Amazing stuff! Makes me want to build my own electron microscope.

Steve.

[J.M. Porup]

How difficult would it be to implement Kali Linux's luksAddNuke patch to
Qubes, ideally on a per-VM basis?

https://www.kali.org/how-to/emergency-self-destruction-luks-kali/

Suggested operation:

password 1 -- decrypts drive, normal operation

password 2 -- nukes a predetermined list of VMs

password 3 -- nukes the whole disk

JMP

[Zrubi]

Just wonder what situation called this feature to reality?


The only one I can imagine is if your data worth much more than your life.

--
Zrubi

[Manuel Amador (Rudd-O)]

I am sure there is at least one scenario where that is actually the case.

--
Rudd-O
http://rudd-o.com/

[J.M. Porup]

Zrubi:

> On 02/16/15 15:40, J.M. Porup wrote:
>> How difficult would it be to implement Kali Linux's luksAddNuke patch to
>> Qubes, ideally on a per-VM basis?
>>
>> https://www.kali.org/how-to/emergency-self-destruction-luks-kali/
>>
>> Suggested operation:
>>
>> password 1 -- decrypts drive, normal operation
>>
>> password 2 -- nukes a predetermined list of VMs
>>
>> password 3 -- nukes the whole disk
>>
>
>
> Just wonder what situation called this feature to reality?

Journalist crossing a border with sensitive documents. Government thugs
demand decryption.

Plausibly deniable per-VM nuking would be ideal in such a situation.
Depending on your adversary, bricking the laptop could still be an
acceptable option.

Think of it as a way of securing Qubes against rubber hose attacks.

JMP

[Andrew]

J.M. Porup:

In that scenario, this would only be effective against a government
agent who attempts to decrypt at the border and just blindly tries your
passphrase.

Of course, most governments (if not all) would be aware of the potential
for data destruction, and would simply seize your device, then analyze
it offline (and only ever work on clones of your disk).
They might detain you, too, then legally or extra-legally compel you to
produce the passphrase.

Even if you encountered such a miraculously dumb government, you might
still be exposing yourself to criminal liability (or worse) for
knowingly causing the destruction.



It seems what you really want is "good old" plausibly-deniable per-VM
encryption, so under duress you can capitulate and give the disk
passphrase, but not all VMs are visible, and no explicit traces of
"extra" VMs exist.

One way to do this might be to basically shard /var/lib/qubes and
qubes.xml, so you can store VMs on separate disks/partitions and load
them (i.e. make Qubes aware of them, so they appear in Qubes Manager and
work with all the tools) at will. Then make sure all Dom0 AppVM logs
are disabled, and make sure you store your TOP SECRET VMs on a
disk/partition that looks like completely random data (at the least: no
lUKS header).

This functionality would have the added benefit of allowing users simply
to store VMs on extra disks, which is a feature request that seems to
appear fairly regularly.

Andrew

[Zrubi]

On 02/17/15 11:28, J.M. Porup wrote:

> Journalist crossing a border with sensitive documents. Government thugs
> demand decryption.

http://xkcd.com/538/



--
Zrubi

[Caspar Bowden]

I would really like to see this implemented

--
Caspar Bowden
Qubes Policy Adviser

[Caspar Bowden]

So this is an oldie and a goodie, but actually many there are many
borders Qubes users might have to cross where governments will not use a
rubber hose

The UK has some of the most sophisticated (and oldest) coerced
decryption laws in the world - here's how they work, and how they (can)
fail

www.fipr.org/sfs8/bowden.pdf

[Andrew]

Caspar Bowden:

As relevant as ever.
Thanks for everything, Caspar.

Andrew

[thinkpad user]

On Tuesday, February 17, 2015 at 3:17:08 PM UTC+4, Andrew wrote:
> (and only ever work on clones of your disk).

this will work only with clones of _not corrupted_ data.
ofcourse user can have special method of destroying data, but having such extra method encapsulates key data nature (location of headers, ...) from user.

if user somehow has low tech knowledge level, it should design and develop tools for traceless data destruction, if failed to find existing. R&D isnt fast and easy task.

> Even if you encountered such a miraculously dumb government, you might
> still be exposing yourself to criminal liability (or worse) for
> knowingly causing the destruction.

only in case of provable intentional destruction