Encrypting Windows Hard Drives
schneier.com
schneier.com
"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...
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.
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.
There were earlier stories from a developer building Bitlocker indicating the FBI did want a backdoor at the time but ultimately settled for this.
You can avoid sending the backup key to the cloud, but I'd advise to keep a backup of this key somewehere: I have had to use a backup key on several occasions after a bad reboot.
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.
The Device Encryption recovery key feature was discussed at length here: https://news.ycombinator.com/item?id=8546524
Certainly, people who are concerned about security should disable/avoid it.
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.
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).
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.
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.
> 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.
I was under the impression that the FDE used by Ulbricht complicated things a lot, and took special measures to get around, and that they were purely lucky to even be able to do so, and he compromised sensible operational security to allow them to do so.
The story goes that they got him in a public place, distracted him momentarily, while someone else swiped the notebook off his desk making sure not to close the lid and kept it from auto locking over time by continuously remaining active with it.
What do you recommend for Windows users?
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.
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?
A 2015 recommendation for Blowfish is cryptographic malpractice.
† unless you're crazy enough to prefer DH to ECDH.
I would appreciate you to cite evidence of people decrypting files protected by Blowfish or IDEA by breaking the cipher.
* Constructions like CTR need to divide the block, in CTR's case to hold both a counter and a nonce. The convention is to use half the block for the nonce and half for the counter, which, in an 8-byte block, means you're working with a 32 bit nonce (much too small) and a 32 bit counter. We actually broke an embedded system that, because of protocol headroom issues, used small counters for CTR mode.
* (Related) That issue more or less rules out all the modern AEAD modes, all of which are specified on 16+-byte blocks, for that reason.
* The smaller block size makes malleability attacks easier. For instance, when you're bitflipping CBC, the edits scramble a block and alter the next. With an 8 byte block, you have much more control over what gets scrambled and what gets edited.
It's cross-platform FOSS instead of the "Hey, buy now!" BestCrypt that this article is pushing.
It's getting increasingly difficult to buy a Windows computer that's not UEFI/GPT, so no OS level encryption.
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.
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...
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...
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.
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.
> It works on non-pro/non-enterprise systems.
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.
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?)
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.
Many, many companies actively spy on their customers, including some of the most successful companies in the world.
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.
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?
I think it's best summarized as:
"Removing the Elephant diffuser doesn’t entirely break BitLocker. If someone steals your laptop, they still won’t be able to unlock your disk and access your files. But they might be able to modify your encrypted disk and give it back to you in order to hack you the next time you boot up"
Vanilla CBC makes it easier to mount attacks, and XTS makes it harder, and the diffuser may have even made it incrementally harder. But no notion of difficulty here deserves the uppercased "Hard" we're looking for with cryptography: at best, you concede attackers "only" the ability to randomize targeted ranges of stored bytes, which --- especially for the mountains of C code we call "operating systems" --- is a devastating vulnerability.
If you are seriously worried about Highly Capable Attackers, and you lose custody of your laptop, you should consider writing it off.
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.
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.
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".
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.
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.
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.
To make a simple comparison: if someone smarter than me says 2+2=5, my probability of 2+2=4 will move go down from (1 - epsilon) to something a bit lower.
Unfortunately, it reduced the security of Bitlocker in a way that is only marginally relevant to Bitlocker's goals, and in a way that is very, very difficult to explain to people who don't routinely work with cryptography.
So it's hard to crisply refute Schneier on this point, even as we have to watch the alarming spectacle of him recommending a rando disk encryption program that offers Blowfish, CAST, and GOST encryption.
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.
... and nobody who just picks up your laptop can either read your files without your password, or remove the drive and gain access to your files without the TPM.
Whether that chain all works as I imagine or not, I can't say and I haven't investigated to be able to say. I don't know if all it takes to gain access to the TPM in reality is (physical access to the machine), a USB stick with EFI booting, and any signed OS that will verify you are a root user authorized by that USB stick, which anyone who has $99 can get on their own, or just download Ubuntu or RedHat on your own can get.
That would be a pretty big let-down if that was really all you needed, though.
The other big threat is that TPMs are probably cheaply built, and anyone with decent hardware skills can probably pop the key out of the TPM. I haven't seen the TPMs in laptops boasting anything like FIPS-140-2 Level 4 validation or any real tamper proof abilities.
But for common users, a TPM+Bitlocker transparently deals with the issue of "left laptop in taxi". Microsoft, AFAIK, allows TPM+Bitlocker in lieu of a smartcard for remote access.
Nullius in verba
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
[1] - https://securelist.com/blog/research/70504/the-mystery-of-du...
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.
Um, no.
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.
I'd also wonder what vulnerabilities would exist in such software. The encryption part is well described, and one would expect it'd be done right (and if it's wrong, that requires rewriting the disk to fix). Other than that, what are we talking about? Bugs in the TPM/BIOS PCR checking? Accidentally writing the keys somewhere? I'm probably being very unimaginative here.
Edit: Let me say I'm assuming you have a password in addition to the TPM. Obviously if you can boot the machine up and have Bitlocker decrypt, and you have access to the machine, you can somehow extract the key if you have the resources.
_NSAKEY wasn't a backdoor. People need to let that go. Not a single line of code was ever discovered that indicated the NSA was utilising it as a backdoor into cryptography, so the entire basis for the conspiracy theory is that the variable which holds the "backup key" happened to have been named that (and that includes the NT4.0/2000 source code leaks).
https://en.wikipedia.org/wiki/NSAKEY
Also Microsoft shares the Windows code with many institutions[0]. Yet none of them, nobody at Microsoft, and not even the Snowden leak indicated a backdoor in Windows.
Microsoft MIGHT have made it easier for the US Government to tap Skype calls (and I believe that they did based on available evidence). Aside from that for all the mudslinging almost none of it ever sticks.
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?
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.
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.
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.
1. Avoid ECC's for commercial activity because NSA & a private company were asserting 130+ patents existed on them. Be ready with lawyers otherwise. Anyone following all the patent battles would be concerned. If not concerned or doing FOSS, I always recommend using Bernstein's NaCl or a double signature scheme with a post-quantum algorithm as secondary for those worried about such things. Lots of good work on Merkle Tree's recently, for instance.
2. Use Blowfish in cascading ciphers with other strong one's such as AES candidates. Cryptographers make barely substantiated claims about things' risk all the time. Worse, their proofs on "secure" constructions sometimes don't even apply to the real protocol rather than an abstraction of it lacking key details (eg padding). Always include things the NSA and other strong attackers have failed to beat for 10+ years. If it was so bad, they'd be dominating it across the board. They not. So, it's either not so bad or good obfuscation to add to stronger stuff.
3. Google's most clever work, which I praised, was NaCl. It ended up being one of the weakest CFI schemes in practice because they sacrificed too much security for performance and maybe other reasons. They continue to build on it despite better stuff available. Much of their other stuff was COTS implementation quality with no specialist security engineering that I could tell. They're weak on endpoints like majority by relying on insecure tools and endpoints. My advice is to think of them like any other vendor rather than on another level. Depending on architecturally-weak TCB's such as Linux doesn't add confidence to any notion you have of strong endpoint security. There are no strong endpoints in mainstream lol.
4. NSAKEY is possible evidence of subversion from a company with a whole history of screwing customers for profit on their own and with government. By itself, not the biggest worry. It's just one more circumstance among many that should get people away from Microsoft tech. Seriously, how many times do BSD or Linux users get into huge debates about something like this where the NSA's actual name dropped in there with secret functionality and evasiveness by developers? If it happens at all, you could name it on one hand. Getting away from such companies is a positive.
5. A risk indeed I took on a PC that was already compromised by my main opponent as far as I knew in a sandbox. I cross-referenced the command against the documentation as I indicated in the conversation. Yet, most people who use software do similar things without cross-referencing. People were likely to Google signify and OpenBSD issues as well along with following steps they saw online. That risk is pervasive. Nonetheless, unlike you, I decided to change my position back to being more careful after a good critique by a commenter. You've only increased your number of attacks with opposition to... anything.
6. Firewalls, as industry uses them, are a weaker form of security than high assurance guards that predated them, strong endpoint security that predated them, or even firewalls on dedicated PCI cards with more secure TCB's & I/O offloading that existed in 90's. The firewalls were easy to port, cheap to make, and often pricey to sell, though! They're regularly bypassed on endpoints and in many organizations' networks. They include almost no assurance activities, which are critical for security. A number of attacks springboarded off of them for this reason and leveraged their privileged position in the network. My position is firewalls are a filter for hackers without talent along with providers of other security or non-security functionality buyers find useful. Industry needs to switch back to guards with real assurance. And not that Linux or Solaris based crap vendors are pushing recently, either.
7. Avoid OpenSSL because every code review of it showed it to be utter crap with all kinds of issues, about the worst coders one could find, and whose reviewers could barely follow it or justify a number of things in it. Consider alternatives like MatrixSSL, PolarSSL, Cryptlib, Botan, and whatever that haven't been shown to be utter garbage yet. They might be better. Shockingly, there were still people recommending OpenSSL even as LibreSSL team dug one problem after another in the worst horror story of bad coding and security of that time. Malpractice, indeed.
"I get the feeling that we do very different kinds of security."
We do. You trust Windows, think such software isn't black box because people can pay millions to fully R.E. it, abandon stuff that works in a use case because someone said to without evidence, trust subversive companies because someone else said to, and so on. Lot's of faith-based activities and misrepresentations of others' comments by stripping context in a totally-unrelated discussion.
My form of security says you (a) have clear requirements proven in practice to work; (b) a design that meets them with strong argument; (c) a security model that makes sense; (d) evidence you use it; (e) implementation designed for review with good layering, modularity, and interface protections; (f) strongest software and hardware protections you can use; (g) extensive testing of successful and failure states; (h) covert storage and timing channel analysis; (i) robust compilation to object code; (j) secure SCM setup; (k) independent evaluation and pentesting of these; (l) delivery of product with source & build tools with hash that matches independent evaluation; (m) preferably mutually distrusting evaluators. All this applied as much as possible from processor up or using diverse hardware with careful interfaces to counter hardware risks a bit.
Yes, a lot of this was borrowed from higer EAL's and papers on high assurance processes/products. Many things like this survived NSA pentesting for years. The other approach, which you & INFOSEC industry in general recommend, has produced things with endless vulnerabilities at high severities and subversions. China, Russia, and TAO are having a field day with it all. Among others. That you all continue to promote such methods despite them having no results for decades hasn't started to make sense to me outside studies on psychology and networking effects. That industry doesn't adopt even a fraction of stronger methods is amazing despite empirical evidence and strong anecdotes showing they produce more robust systems. The industry continues to focus instead of churning out low-quality offerings and deceiving buyers on their security for the high profits involved.
Keep it up, though, as black hats need the job security. Mainstream INFOSEC has always helped them with that. The oft-ignored high-assurance community will continue doing what we can and helping any willing to learn understand strong security. Although, in this thread, only the firewall point even applied to my expertise as it's a watered-down guard in terms of assurance. The others are a random assortment of comments with no supporting context given. Nonetheless, you seemed to be confused about what strong security engineering takes and I was happy to break it down for you. Have a good night.
Cries for tptacek to produce evidence, for example, of the reversibility of Windows code, would be more pleasantly satisfied by some deeper investigation, such as discovering React OS. It would be surprising to me for anyone to conclude that Windows code has not been totally, and publicly, reverse engineered.
It is not a big leap from there for you to investigate from that code the true nature of NSAKEY. My guess is that you would find that there is no there, there.
Your statement My form of security says you (a) have clear requirements proven in practice to work; reminds me of my youth, when I discovered the writings of Dijkstra and others, talking about proving programs correct. While this is a wonderful idea, and a small handful of folks have actually done this, modern business doesn't seem to want to stand still for Category 5 maturity.
While you denigrate OpenSSL and its code quality, keep in mind that several of the high-severity bugs, such as BEAST and CRIME were not code quality bugs, but essentially protocol bugs. The perfectly-specified requirements (implement compression in HTTPS) could have been backed up by code proved correct, and still exhibited the flaw. Similarly for BEAST.
Also, one wonders if you have tried to break real-world crypto. If you haven't, I suggest that you give some of the online exercises a try. It is rather eye-opening.
Finally, many statements in your comments mischaracterize the points arguments make. This has become more than annoying. Please stop.
The subject we were talking about was massively debated by IT people. Nobody showed up with the code to say, "Here's the reverse engineered code. We know exactly what it does." If he was right, that should've happened. Instead, all references I found to the subject by INFOSEC professionals are trying to guess what it did. So, I think it's fair to ask for a reference to slam-dunk evidence supported by reverse engineering if none is to be found with Google & nobody involved acted like it exists. Only source so far is tptacek's word.
"While this is a wonderful idea, and a small handful of folks have actually done this, modern business doesn't seem to want to stand still for Category 5 maturity."
I agree. It's why I don't work in high assurance security any more outside consulting, R&D, and free advice on the Internet. I'll add to your comment that this is not just for heavy-weight processes. Cleanroom & Fagan Inspections, which I used, drove the defect rate close to zero while often reducing the labor due to less time debugging & with little impact on time-to-market. The Cleanroom stuff, when apps were similar, even had statistically certifiable bug rates we used to issue warranties on code. Despite no extra time or cost, virtually no company we presented those processes to were interested in using them. Demand in IT and INFOSEC space is so against quality you can't even sell it to majority even if it makes money rather than costs it. It's that bad.
"he perfectly-specified requirements (implement compression in HTTPS) could have been backed up by code proved correct, and still exhibited the flaw. Similarly for BEAST."
Totally true. It's why I mention getting requirements and specs right. Even CompCert, an amazing piece of engineering, eventually had flaws during a test because the specs on very front and back ends were wrong. Other side of the coin: implementation of of all specs flawlessly implemented them with middle end having zero defects. Every other compiler, from proprietary to FOSS, had bugs throughout. So, the existence of protocol errors doesn't argue against verified software processes in any way. Just means your protocol better be as good.
And if it wasn't clear, my gripes on OpenSSL were based on the commit logs of LibreSSL team commenting on each piece of code as they went through it. I'm not talking the protocol at all: just terrible coders making garbage that got widespread adoption without hardly any review. Unsurprising given my above comments on how IT market works.
This is not only false, but falsified by this exact thread.