1 |
On Sun, Nov 30, 2014 at 5:19 PM, Mick <michaelkintzios@×××××.com> wrote: |
2 |
> On Sunday 30 Nov 2014 19:05:52 thegeezer wrote: |
3 |
>> *if* you trust it is not backdoored |
4 |
> |
5 |
> Well, yes, in the post Snowden era I do not trust it. At all. |
6 |
> |
7 |
|
8 |
Keep in mind that you have to consider your threat model. I think it |
9 |
is fairly likely that the NSA has backdoors into most TPM chips (I'm |
10 |
not sure I'd even limit that to US-made chips). On the other hand, I |
11 |
also consider it likely that the NSA has zero-days for every browser |
12 |
around, and likely privilege escalation attacks against linux, and |
13 |
maybe even attacks against most of the hypervisors out there. If the |
14 |
NSA REALLY wanted your data, then they're going to get it. Of course, |
15 |
some attacks are a larger concern than others. Actually accessing a |
16 |
TPM back-door, or utilizing a zero-day, likely requires actively |
17 |
modifying your internet traffic, which carries a risk of detection. |
18 |
They won't hesitate to do that if they are on the trail of some |
19 |
terrorist, but they probably won't do that as part of some kind of |
20 |
widespread surveillance net since there would be a pretty high |
21 |
likelihood of detection if they did that to everybody, and then they |
22 |
lose their zero-day. On the other hand, if TPM-seeded random numbers |
23 |
aren't really random then they might be able to passively decode your |
24 |
SSL traffic which is something that would be almost impossible to |
25 |
detect, and that could be done as part of an effort to read |
26 |
everybody's TCP streams. |
27 |
|
28 |
Honestly, I don't really worry about the NSA. If they want to read my |
29 |
traffic they're going to do it, and the only way to stop them would be |
30 |
to wrap so much tinfoil around my head that I basically couldn't |
31 |
interact with anybody online. I'm more concerned with things like |
32 |
identity theft, cryptolocker, physical theft of laptops, and so on. A |
33 |
TPM provides a significant level of protection against some of these |
34 |
attacks. LUKS does as well, but at a cost of convenience and a risk |
35 |
of downtime if you're running it on a server and it ends up rebooting |
36 |
when you aren't around. Why would you care about full-disk encryption |
37 |
on a server? Well, ever have a hard disk die on you? Can you |
38 |
guarantee that when a hard drive dies that you'll always have the |
39 |
ability to wipe it before returning it for a warranty swap? With full |
40 |
disk crypto you're safe even if you can't wipe it. |
41 |
|
42 |
-- |
43 |
Rich |