
Encrypting Windows Hard Drives - jron
https://www.schneier.com/blog/archives/2015/06/encrypting_wind.html
======
jron
I think this is worth repeating:

"I asked Microsoft if the company would be able to comply with unlocking a
BitLocker disk, given a legitimate legal request to do so. The spokesperson
told me they could not answer that question." \-
[https://firstlook.org/theintercept/2015/06/04/microsoft-
disk...](https://firstlook.org/theintercept/2015/06/04/microsoft-disk-
encryption/)

~~~
nickpsecurity
It doesn't mean anything because it's a standard move to reduce legal risk. No
comment is almost always the safest answer. This applies to individuals too:

[https://www.youtube.com/watch?v=6wXkI4t7nuc](https://www.youtube.com/watch?v=6wXkI4t7nuc)

~~~
belorn
It is a move to reduce trust in a market where trust is the single most
important aspect. Schneier's article is all about whom he trust, why he trust
them, and conclusion he makes based on that trust.

If you bought a security product and the developer of it describes its
strength as "No comment", would you trust it? Personally I am sticking with
the abandoned TrueCrypt until a successful fork has been created or luks +
dmcrypt has been ported to windows.

~~~
nickpsecurity
If you were right, then the most trustworthy companies would have the most
market share while offering us good EULA's. Looking at top software names,
it's clear trust and success in the market place have almost nothing to do
with each other. It's actually opposite with the dirtiest companies on top in
most places. Negative media definitely hurts the bottom line but majority of
time isn't an issue. They have PR people for that.

There have always been companies that share source with customers, use
stronger security tech, warranty their code, and so on. They were minority
players pre-Snowden with many having left that market because so few cared.
(myself included) Post-Snowden, they're still minority players with the market
mostly going for whoever promises the most on their web sites & in media.
Trust and security have always come 2nd (5th?) to all kinds of other criteria
for buyers in the IT market. If you doubt, look at number of Facebook or Gmail
users vs number using more private alternatives. People & companies sell
themselves out in droves.

------
themeek
Bitlocker (well, "Device Encryption") does upload your harddisk keys to
OneDrive by default, and OneDrive is onboarded to PRISM for government
request.

So in the case that you end up provisioning a computer or device with
Bitlocker, the key may very well end up in a database for query.

Outside of this it's not really so speculative to think that Bitlocker has
backdoors for gov't access. It's unlikely that Microsoft Bitlocker survived
the combined forces of state-of-the-art cryptanalysis, legal compulsion, and
company infiltration (exposed by Snowden).

A backdoor for disk encryption need not directly attack the cryptography. It
could be something as simple as a means to generate a bunch of predictable
blocks on the harddrive - that's enough to break XTS. That is, even if there's
no software backdoors or backdoors build into the TPM (Lenovo, for example,
has 'key escrow' capabilities to extract Bitlocker keys out of TPMs) or crypto
backdoors in HW PRNGs (e.g. Intel RDRAND), etc there are software bugs in
other places that could reveal the contents of the hard disk.

So it's merely not a threat model you're ever going to find a solution for. In
the very worst case, presuming there were some mystical level of harddisk
encryption that was't trivial to backdoor or break by a sophisticated
adversary - intelligence folks can use TEMPEST attacks, break into your
computer when you turn it on, and/or get rubber hose access. An encrypted disk
will not stop Mossad.

There is no disk encryption that will unilaterally prevent USG from accessing
your files (you can only make it more expensive).

But as the USG is fond of repeating - you don't need your disk encryption to
protect you from the government unless you have something to hide. You only
need it to prevent attacks from criminals and for device theft.

~~~
tptacek
Can you explain more carefully the XTS attack you're contemplating here?

The Device Encryption recovery key feature was discussed at length here:
[https://news.ycombinator.com/item?id=8546524](https://news.ycombinator.com/item?id=8546524)

Certainly, people who are concerned about security should disable/avoid it.

~~~
themeek
Sure. XTS reuses the sector-block for an IV, and so on a per-block level
encryption is deterministic. The flaw here would be a scenario where there are
deliberate repeated modifications to blocks of the harddrive (somewhere like
within hibernation/wake code). Something carefully designed could, in theory,
lead to the compromise at a block level that would allow tweaking of some
contents on the disk (say, contents of the registry, or of some boot switches,
etc) that would in turn enable the machine to be booted and the disk to be
decrypted.

It's also true that the TPM protector for bitlocker uses a pin with max ~20
bits of entropy to shield the bitlocker key from exfiltration. The TPM is
supposed to lock out repeated requests to extract they key but given the heavy
involvement of the NSA in designing the TPM spec and its similarity to the
Clipper Chip in function (so too with Apple's "Secure Enclave"), and its
difficulty to audit (as if mom and pop consumers really need protection from
adversaries who are going to reverse TPM chips to get computer data), one
can't help but to acknowledge that a backdoor could easily exist there.

All of this is hypothetical of course. I don't claim to know that this sort of
attack is there or that it is placed deliberately. I'm merely trying to make
the point that a backdoor need not be in the harddisk encryption code itself.

~~~
tptacek
I'm still not clear. XTS doesn't have an IV; it has a tweak key. It's
deterministic (which also means it can leak data, ECB-style, across successive
encryptions of the same sector). The tweak key is simply the product of the
encrypted sector number multiplied by a polynomial; I don't understand what
tricks you can play with it.

The fundamental attack you seem to be describing --- that an attacker can
rewrite the contents of the disk --- applies to practically every sector-level
cryptosystem; none of them are authenticated. But XTS can't productively use
"patterns" of disk blocks, unless there's a clever attack I don't know about
(hence me asking).

~~~
themeek
No, we're on the same page. I don't have an attack on XTS you are not aware
of.

Code (again pretend in hibernate/wake behavior) that deliberately leaks
information about important boot blocks on the disk could lead to a full
compromise. The attack and back door, of course, would be fairly sophisticated
in this instance.

You'll concede that the possibility exists, but that its hard to evaluate.
What I'm trying to contribute is not that such a backdoor is currently used (I
have no idea) - but that RDRAND/TPM/XTS-leak or other non-Bitlocker backdoor
can be used to thwart Bitlocker if we imagine that it hasn't been directly
backdoored.

~~~
tptacek
I'm honestly still not following the XTS leak you're talking about. The
deterministic leak I'm talking about happens because XTS isn't randomized: as
you write and rewrite the same sector, you're doing so against the same set of
"tweaks". I think that's a meaningful problem --- particularly if you're using
XTS to encrypt something other than a disk, particularly in a cloud setting
--- but as a backdoor, it's a pretty crappy one, because it requires your
computer not only to be on and "unlocked", but also for you to continuously
update the targeted blocks.

It's an especially dumb backdoor for Microsoft, who could literally backdoor
the Comic Sans TTFs to greater affect. Why would they tamper with the most
sensitive code on the entire system, to get a fifth-rate backdoor, when they
could get a first-rate remote backdoor out of virtually any code on the whole
system?

Subtextually: I just generally dislike FDE, as anything more than a "my
computer got stolen out of the back of my car" mitigation.

If you are worried about attackers with continuous high-touch access to your
computer, no FDE system helps you. Reliance on FDE more or less made the DOJ's
case against Ross Ulbricht, for instance.

~~~
themeek
> as you write and rewrite the same sector, you're doing so against the same
> set of "tweaks".

> but as a backdoor, it's a pretty crappy one, because it requires your
> computer not only to be on and "unlocked", but also for you to continuously
> update the targeted blocks.

The hypothetical backdoor in this example would be in
boot/hibernate/wake/suspend/whatever code - i.e. not "on and 'unlocked'".
That's the entire point of this backdoor. If the computer needs to access
encrypted parts of the disk during boot - even if encryption is done by an
e-drive rather than in software - code that causes repeated writes (or even a
single write) to an important sector could be designed to subvert FDE.

But it doesn't really matter about this particular hypothetical. We both agree
that there is plenty of room to backdoor Bitlocker without having to rely
specifically on bitlocker code.

------
tptacek
It's a little disturbing to see Schneier recommending a disk encryption
package that offers to encrypt drives using CAST, GOST, and Blowfish.

~~~
nickpsecurity
He's currently recommending, for Windows users, either Bitlocker (256-bit AES)
or BestCrypt (256-bit AES, RC6, Serpent, or Twofish). Not whatever link in the
article you found those in. Unless I overlooked them in Bitlocker or
BestCrypt's spec pages...

About those, though, CAST-128 isn't trustworthy (chosen-plaintext attack),
GOST is probably there for Russian market, and Blowfish is fine given all the
beatings it survived (good sign of security). I still use Blowfish and even
IDEA in my polymorphic ciphers that semi-randomize a combination of strong
ciphers along with counters.

~~~
tptacek
Blowfish and IDEA are _not_ fine. They're block ciphers with 8-byte blocks.
They are both materially less secure than AES. Recommending them is borderline
malpractice.

~~~
nickpsecurity
You have an attack on them? One that works with a Top 500 supercomputer? With
a IBM Bluegene? With a FPGA? With Intel hardware most black hats have?

IDEA particularly was a thorn in the side for NSA via the most famous app
using it. Academics gave it plenty of beatdown. It's still secure in practice.
So is Blowfish if working around weak keys and rotating frequently. My motto
in high security is "tried and true beats novel and new." An new thing shows
up with new methods, new proofs, and a few years later new attacks. I'll take
the thing that works despite tons of effort to make it not work.

That said, remember a cascade is my usage case. AES finalists received
enormous peer review. At least one of them is always used. The weaker ciphers
are in the middle. Then, there's stream ciphers such as Salsa20. Ciphers that
are the same can't be used in a row (meet in middle). Any pro looking at the
construction hasn't identified a realistic risk in years far as the crypto
goes. Protocol implementation, RNG's, parsers, etc were the usual worry areas.

So, I call FUD on this stuff. It's one of the things cryptographers always
bring up without evidence of any practical risk. I'm confident that,
accounting for weaknesses, certain algorithms are strong after still being
secure for 10+ years of significant use and cryptanalysis. That's a good track
record without a break in INFOSEC, right?

~~~
tptacek
Yes, there are real attacks on constructions build from 8-byte blocks. And no,
that's not how real-world crypto attacks work; we don't use supercomputers to
mount brute-force searches.†

A 2015 recommendation for Blowfish is cryptographic malpractice.

† _unless you 're crazy enough to prefer DH to ECDH._

~~~
nickpsecurity
I believe it's possible. It's why I only use it in cascades. Yet, where's the
practical attack where IDEA and Blowfish traffic are decrypted with
ciphertext? If it's malpractice, then they're either fully decryptable or will
be soon based on existing attacks on specific numbers of rounds or
implementations.

I would appreciate you to cite evidence of people decrypting files protected
by Blowfish or IDEA by breaking the cipher.

~~~
tptacek
"Pizza? Now that's that I call a taco!"

[https://vimeo.com/90127834](https://vimeo.com/90127834)

~~~
nickpsecurity
Exactly. Nada again.

------
skrowl
Since the death of TrueCrypt, I've been using VeraCrypt
([https://veracrypt.codeplex.com/](https://veracrypt.codeplex.com/)).

It's cross-platform FOSS instead of the "Hey, buy now!" BestCrypt that this
article is pushing.

~~~
kijin
VeraCrypt looks good, but incompatibility with TrueCrypt volumes makes me
uncomfortable with switching. I've also looked at CipherShed and DiskCryptor,
but the fragmentation gives me no assurance that I'll be able to access my
encrypted volumes several years from now.

So I'm still stuck with TrueCrypt 7.1a. After all, it's the only disk
encryption software for Windows that has been independently audited. None of
the purported replacements and proprietary alternatives can lay claim to that
distinction, no matter how much Bruce Schneier might personally trust the
developers.

~~~
userulluipeste
I've found about DiskCryptor trough ReactOS driver signing page:
[https://reactos.org/wiki/Driver_Signing](https://reactos.org/wiki/Driver_Signing)
They say that they review the code the result of which they offer signature
for. Is or isn't that enough for "independently audited" label?

~~~
kijin
Review != security audit.

------
unsignedint
One problem I have with BitLocker is that it's only supported on
Ultimate/Enterprise (on 7) and Professional and up (on 8)

I guess one could argue about not having those editions in a business setting,
but the vast majority of pre-installed Windows in a market is Home Premium,
and I can't think of enough justifications (especially in small businesses)
for higher editions, and besides, many people, in home setting would want to
have this extra protection for their computers. (After all, they do banking,
tax, etc.) -- It seems like non-pro 8.1 does BitLocker for system drives, but
then it also comes with a bit of "only if's" (InstantGo, SSD, non-removable
RAMs, TPM, etc.)

As someone else mentioned here, it seems like choices are starting to become
narrow as fairly limited solutions can support UEFI/GPT, too...

~~~
Someone1234
Windows 8.1 and above now have a type of "poor man's bitlocker" simply called
drive encryption. It works on non-pro/non-enterprise systems.

It requires a TPM, uEFI, and Microsoft Account. But once you meet the
requirements it gives you a "basic" level of encryption which for a petty
criminal is hard to break. Most Surface Pros 3 will have this enabled already.

[http://www.howtogeek.com/173592/windows-8.1-will-start-
encry...](http://www.howtogeek.com/173592/windows-8.1-will-start-encrypting-
hard-drives-by-default-everything-you-need-to-know/)

Legit Bitlocker is superior in many ways (in particular not having to store a
backup key in a Microsoft Account, and having more choices about how to
decrypt). But for consumers it is a very welcome addition.

~~~
wlesieutre
> It requires a TPM, uEFI, and Microsoft Account. But once you meet the
> requirements it gives you a "basic" level of encryption which for a petty
> criminal is hard to break. Most Surface Pros 3 will have this enabled
> already.

Are you sure this is accurate? I'm using a Surface Pro (comes with Windows
Professional), and when I go to the BitLocker settings (in Control Panel) it's
shown as enabled. I haven't changed from whatever the default settings are.

~~~
yareally
I think you missed reading part of the comment that implied it worked on
Professional:

> It works on non-pro/non-enterprise systems.

~~~
wlesieutre
Right, I'm wondering about the assertion that the SP3 came with a "poor man's
BitLocker called Drive Encryption" enabled. The BitLocker preferences tell me
I have BitLocker enabled.

------
Kenji
_If it ever turns out that Microsoft is willing to include a backdoor in a
major feature of Windows, then we have much bigger problems than the choice of
disk encryption software anyway._

That might be so, but proper encryption is still valuable. Say you have a disk
full of sensitive information. Say your computer was turned off as the
adversary gets hold of it. If you have a proper encryption program, no OS
backdoor will be able to decrypt it retrospectively (that is, when it's
activated after the bust). Broken encryption makes you vulnerable even when
you're offline or the PC is turned off.

~~~
marcosdumay
Way to miss the point.

If you run Windows, Microsoft has complete control of your computer. Unless
you never turn it on, MS can log all the keys you press, all the data on the
disk, all the network traffic, or really anything else they want at will.

If you trust them not to do the above, why wouldn't you trust them to encrypt
your disk too? (Unless you don't trust their competence. But then, you are
trusting them to secure your computer while it's on, but not when it's off?)

~~~
RaleyField
> Microsoft has complete control of your computer.

So does any Linux distro if you don't compile from sources yourself. Who
knows, maybe Debian openssh fiasco was an inside job.

> why wouldn't you trust them to encrypt your disk too?

I trust them that they wouldn't be actively spying on their customers, because
that's a good way to kill your company. I don't trust them they tried their
utmost to secure our computers (we'd be running Singularity/Midori/Verve
otherwise), because they are likely being coerced to comply with various
orders and regulations.

~~~
marcosdumay
> So does any Linux distro if you don't compile from sources yourself.

Yes, that's a good start. You just didn't go far enough.

Endpoint security is a messy problem, where everything is expressed in shades
of gray. Yet, spying on your computer when it's powered, and backdooring your
disk encryption for when it's off do not differ in luminosity enough to be
called different colors.

By the way, yes, Microsoft was already caught spying on their users. More than
once.

~~~
RaleyField
> You just didn't go far enough.

99.9999999% don't go far enough. Evidently everyone using Debian for those
couple of years didn't go far enough. Not even two whole bytes of entropy is
insane.

> By the way, yes, Microsoft was already caught spying on their users.

Surely allegedly. I've heard a few incidents attributed to them (flame, etc),
but I've not seen it confirmed that intentional action was taken. Care to
provide the links?

------
MichaelGG
Since he knows Niels Ferguson and understands cryptography, why doesn't Bruce
get some proper analysis or statement regarding the damage of removing the
diffuser? Seems like that's one obviously big elephant in the room here.

~~~
tptacek
What analysis are you looking for? The purpose of the "diffuser" is well-
understood, as are the security implications of losing it. This comes up on HN
about once every other month, on threads you've been a part of. What part of
the explanation you've gotten here seemed inconclusive?

~~~
MichaelGG
Bruce cites removal of the diffuser as a specific reason he no longer thinks
Bitlocker is OK. If that's really what he thinks, why doesn't he say exactly
why? There are practical attacks on Bitlocker without the diffuser, but
Ferguson stated he didn't believe there would be with the diffuser (in the
original Bitlocker paper, I think).

Your explanation, that the diffuser doesn't make it Hard, is understandable
and it's not something I'd worry about. And the way you phrase it, it seems
unarguable and straightforward that it isn't a big deal, that no one should
ever rely on FDE for integrity. But Bruce understands a lot more than me, and
he's citing this as a big deal. And MS/Ferguson originally made a big deal out
of it. So was it always just a useless add-on? Wouldn't someone have published
a paper showing how Elephant doesn't really help? Certainly a practical attack
on it would be notable?

I hope you can appreciate my confusion.

~~~
tptacek
We don't have to read tea leaves about what Schneier does or doesn't think,
because the engineering issue here is straightforward. Ferguson wrote a paper
about the CBC+diffuser construction, and what it's goals were. On a previous
thread, 'pbsd even pointed out that the performance issues made sense: the
CBC+diffuser construction couldn't easily benefit from hardware AES
instructions, which harmed performance.

~~~
MichaelGG
I'm only trying to be rigorous in my evaluation of the evidence, since I'm in
no position to judge the actual strength of the diffuser. Yes, this is
probably just academic, as I wouldn't trust a disk with suspected tampering.
(Or if that was required, like storing VHDs on a hosted block device, I'd
store a hash of the disk or executables.)

Anyways, my reasoning:

1\. The diffuser didn't really help for serious threat scenarios, and hurt
perf, so no one should be upset by its removal. This seems to be true.

2\. But MS previously called the diffuser critical and has made no statements
as to the security impact of the removal. (Indeed, there are easy attacks
without the diffuser, but no known attacks with it.)

3\. A well-known cryptographer (Bruce's actual cryptography credentials are
undoubted, correct?) cites the removal as a reason to be suspicious.

If 1 is true, which I think it is, then 2 and 3 are at odds with how reality
should be. No matter how confident _I_ am in 1, points 2 and 3 require a shift
in the probability of 1. Or, I am misunderstanding 2 and 3.

How else should I evaluate these things? Sorry for being dense or wasting your
time.

~~~
tptacek
Bruce Schneier has said other dubious things about crypto in the past; for
instance, about not using elliptic curve crypto, and preferring instead
conventional DH.

Again though: if the lack of a "diffuser" is a reason to be "suspicious" of
Bitlocker, it should be possible to explain why that would be. I tried to
address that concern head-on. It bugs me that we keep having to flee back to
"but Schneier is concerned".

~~~
Tomte
Especially egregious was the episode where he misunderstood the "xkcd password
scheme" and lashed out against it in his blog, and then kept on defending his
flawed opinion against all explanations.

That did a lot of damage to all attempts to teach password security to laymen.

OTOH he was one of the first "famous" security people to publicly recommend
writing down passwords.

So all in all he is certainly a net win.

~~~
tptacek
Cryptography Engineering is a good book (with some flaws).

Schneier is _much_ less of a factor in real-world crypto than generalist
developers think he is.

I feel bad blaming him for it; it's not his fault that people who don't do
serious work in cryptography have made him a cryptographic folk hero. On the
other hand: there are still people using Blowfish because his name is on it,
so maybe I don't feel bad blaming him.

~~~
Tomte
Oh, certainly (I was just talking about passwords)!

Cryptography Engineering is something I hold very dear and have lent out to
colleagues. Very well written, so it's an enjoyable read. And a good length,
not a thousand pages tome.

My main problem with Schneier at this point is that he pivotted (Ha! This is
HN after all...) from cryptography and technical analyses to political
commentary. And I haven't found him very convincing in that regard. Even
annoying at times.

------
darkhorn
There are some motherboards that can store the encription key so that you
don't need to type the pasword again when booting. BitLocker supports it. What
a great technology. It saves your life!

~~~
wfunction
Sounds like it completely defeats the point of encryption.

~~~
jhallenworld
You could store the key (or password to the key) in the TPM in order to
prevent BIOS, bootloader or option ROM tampering.

An issue is that too many things could affect the TPM PCR values (for example,
plug in a USB stick even though you don't boot from it- I think this is a
mistake in the spec), so users get used to typing in the backup password and
may not notice that a root-kit was installed.

~~~
MichaelGG
In my experience of using Bitlocker for years, it's very rare that I have to
enter the backup password. Even when I changed the default PCRs used.

------
spacehome
> BitLocker is Microsoft's native file encryption program. Yes, it's from a
> big company. But it was designed by my colleague and friend Niels Ferguson,
> whom I trust.

Nullius in verba

------
adrianscott
Certainly there is 0% chance that the author is asking us to read between the
lines here... #FaceValue

------
revanx_
There may not be any deliberate backdoor in BitLocker however I think it's
safe to assume that NSA has access to the source code, probably found some
angle to exploit.

~~~
tptacek
What's the disk encryption offering you think NSA doesn't have source code to?

~~~
nickpsecurity
That's a good point. Any product of significance that runs in software on
untrusted users computers can be compromised by determined attackers, NSA or
not. Even hardware-protected secrets have been bypassed. Hence, the security
argument must rest on something that works regardless of whether enemies know
the mechanism.

~~~
erhardm
I think that's the Kerckhoffs' principle[0].

Regarding to state actors who have the resources to attack any system, I think
it's important to make it as hard as possible, even if it's "known" they will
find a way. Why?

Because it will drive the costs very high with years of R&D having as result
that they'll only use new attack techniques on high-level targets and that
means risk of revealing attacks goes up(assuming high-level targets are more
sophisticated and spill the beans - as in Kaspersky case[1]).

[0] -
[https://en.wikipedia.org/wiki/Kerckhoffs%27_principle](https://en.wikipedia.org/wiki/Kerckhoffs%27_principle)

[1] - [https://securelist.com/blog/research/70504/the-mystery-of-
du...](https://securelist.com/blog/research/70504/the-mystery-of-
duqu-2-0-a-sophisticated-cyberespionage-actor-returns/)

~~~
nickpsecurity
I agree. I've been holding High Strength Attackers, as I call them, off for a
while. The formula that works on software attack side is a combo of (a)
strongest security engineering we have, (b) obfuscation at every level, and
(c) diversity of hardware & software components with predictable interface.
One simple example that worked well for years was using a hardened Linux/BSD
box on a PPC behind a guard. Guard narrowed communications to app level while
wiping out covert channels and modifying patterns to resemble other OS. All
evidence from fingerprinting tools would suggest they're connecting to an x86
box, even Windows maybe. All their attacks, some I still don't get, failed to
work on the box.

Most deployments use more tricks than that. I was just amazed at how long that
one went on without compromises. Used same trick for desktops with custom
client-server apps. These days, I'm working on CPU's that protect pointers &
code while tools randomize (i.e. diversify) the application automatically.
Orange Book era solution to secure networking, email, & databases still work
with minor tweaks. I use hardened client-server schemes instead of web apps to
avoid... more than I can count. TEMPEST safe + 100yds of space where
applicable. High assurance security = build on what we know works & eliminate
anything risky where possible. Obfuscations & diversity I add as you said to
just slow down our shadowy friends with deep pockets & large staff. Works well
so far.

------
venomsnake
Do we have good container encryption that mounts them as drives on windows? I
never understood the point of whole disk encryption stuff.

------
ikeboy
>when Microsoft released Windows 8

Um, no.

------
higherpurpose
I don't think Microsoft is ever going to risk putting a Backdoor™ in Windows
after NSA_key or at the very least after the Snowden document leaks + OPM hack
(which both prove the US government's incompetence in storing classified
information securely, which means the company's backdoor could be exposed at
any time).

But that doesn't mean Microsoft isn't going to make it _easy_ for the NSA to
bypass its security. We've seen several reports of that from the Snowden
documents, and it affects OneDrive, Outlook, Skype and probably even
Bitlocker.

All Microsoft needs to do is not fix a vulnerability _it_ finds out about (not
a third party that reports the vulnerability to the company, as they would
have no choice but to fix that). And it doesn't even need to do that
_indefinitely_. It could fix it when a new vulnerability appears, and it can
rotate them every 6 months or so.

Then it can either directly give that vulnerability to the NSA through all the
"cyber sharing programs" where Microsoft has been a "volunteer" for years (way
before Apple), or it can let NSA "discover" it on its own, which can be as
easily done as Microsoft's security researchers talking about a new
vulnerability internally through channels that don't have strong end-to-end
security.

~~~
tptacek
Please stop spreading FUD about "NSAKEY". It's an Alex Jones Infowars-level
conspiracy theory that has been comprehensively debunked.

~~~
nickpsecurity
Actually, I looked into things as promised. The Wikipedia links and whatever
popped up in my Google searches. Turns out the only citation you had, a HN
news commenter, was just repeating the claims of a MS spokesperson with some
added opinions. I found a more interesting source which has similar claims:

[http://cryptome.org/nsakey-ms-dc.htm](http://cryptome.org/nsakey-ms-dc.htm)

On the surface, it seems believable. However, like Duncan, I'm seeing glaring
problems with these responses. It boils down to this: the Microsoft rep
claimed they came up with all details (including the key & its name) on their
own without NSA intervention, generated/control both keys themselves,
submitted the design for review, and got NSA approval. Yet, without NSA's
involvement, a developer named their key NSAKEY and when decrypted its email
was "postmaster@nsa.gov." Also, as Duncan noted & my HSM guy as well, it's
standard for HSM's to let you export keys for backing them up or multi-site
usage.

So, their claims are highly unusual, suspect, and weak. The evasive behavior
that led up to this isn't typical of even Microsoft. They usually come up with
some CYA BS rather quickly. Also, the odds of a Microsoft-controlled key they
made entirely on their own being called NSAKEY with NSA's email on it without
NSA participation are low albeit possible (dev joke).

Far from Alex Jones stuff, there's actual substance to worries over what
NSAKEY did or does. I agree with critiques that it's a lower concern given all
the attack angles on Windows from outside or inside perspective. Yet, dozens
of reports didn't show anything along lines of "comprehensively debunked."
Instead, we had a series of weak stories from Microsoft that raised more
questions than answers with plenty of evasion on their part. And they're known
to work with NSA. So, people should still not trust that and use the steps
that one person published to replace the key with their own.

Solves the problem with minimal fuss, eh?

~~~
tptacek
This is a very long source from 2000 that says in 6500 words what 'geofft said
in just ~300: that this is a code signing key for crypto libraries. If
Microsoft wanted to backdoor your Windows machine, _they already have complete
control over Windows code signing_. They do not need a special key literally
labeled "NSA_KEY" to do that.

It's not "lower concern". It's not a concern at all. Microsoft's code is
comprehensively reverse engineered. People have reversed the most boring,
tedious libraries on the system looking for memory corruption bugs. You posit
that maybe they just forgot to look into this "NSA_KEY" business.

For a software security professional, you really come loaded for bear with a
lot of weird advice:

* Avoid elliptic curve and use conventional Diffie Hellman and RSA because the NSA controls the ECC patents (?!).

* Use Blowfish because it has a long security track record (?!).

* Watch out for Google because they don't understand endpoint security (?!).

* NSAKEY isn't a high-priority issue but it's something that people should be concerned about (?!).

* Here's an unencrypted HTTP website that you can cut-and-paste GPG commands from instead of reading the manual (?!).

* Firewalls are just some made-up crap that don't actually provide any security (?!).

* Use MatrixSSL and PolarSSL instead of OpenSSL because OpenSSL's code quality is crap (?!).

I get the feeling that we do very different kinds of security. You talk a bit
about formal verification and EAL levels. I had the misfortune of losing a
couple months of my life in the early 2000s to Common Criteria work. If you're
coming from a CCTL background, some of the very weird perspectives you have on
this stuff start to make sense to me.

~~~
nickpsecurity
They forgot to look into the subversion, BIOS, peripheral firmware, and covert
channel risk despite me repeating those on forums all over going back years.
Then the shit ended up in TAO's catalog (including my "amplifying cable"
concept aka RAGEMASTER) & most stuff was weak to it. Same argument could
applied to widespread open source software that people find "previously
unknown" bugs in despite that code existing for years and "widely reviewed."
So, I don't have to posit anything given the horrid state of INFOSEC and app
review going back years: they should instead prove they did better than usual
in the security analysis and show what they found for independent review. This
is, coincidentally, a part of the scientific method as well.

You instead could've settled this argument if you linked to a group that
reversed engineered all of that, found that it did exactly what they said, and
had no conflict of interest with U.S. government. You say you _know_ these
exist but still haven't produced them. You instead expected people to take
your word for it or comb the Internet looking for the proof you allege. Both a
tall order.

Those of us in INFOSEC against highly subversive opponents don't deal in pure
faith [esp in similarly evil organizations]. So, where is this evidence that
it was totally reverse engineered and proven to be functionally equivalent to
claims? I'd like to read it, determine its credibility, pass it onto peer
review, and share it widespread if it passes enough of that. As promised, I'll
even add it to the Wikipedia article that tops search to this day.

Waiting on you and your evidence.

~~~
tptacek
No part of this comment addresses anything that I said. This is a pattern with
our interactions: I bring up something specific, and you change the subject,
usually to a flurry of Snowden jargon (this time it's the spy-mall catalog).

We were talking about the transparency of the Windows kernel.

It's a little funny that you feel like you need proof that the code has been
reverse engineered, as if there were like 4 people in the world who could do
it, one of whom is in a mental institution, 2 of whom are in Russia, and the
last is hiding in a monastery in Tibet. You know, as opposed to something you
could literally learn from a book that was on the shelf at Borders, back when
they still sold books retail.

