Summary: Cryptome has an article, comprised/composed of hard evidence, revealing ways in which Microsoft enables aggressive spies to break encryption
The FBI does not even pretend not to be pursuing back doors; quite the contrary! It demands them and now insists on legislation that would make them mandatory. The same goes for the NSA, Microsoft’s very special partner. Anyone who still thinks that back doors in encryption are within the realm of “conspiracy theory” must not have paid attention. We wrote about such issues more than half a decade ago. At this stage, judging by thousands of articles on the topic, these factual observations are very commonplace in the press, even in the corporate media.
“Anyone who still thinks that back doors in encryption are within the realm of “conspiracy theory” must not have paid attention.”“Microsoft backdoor bitlocker key escrow for the FBI & NSA,” writes to us David Sugar from GNU Telephony. “From the OS that loves to spy on you,” he added.
Some months ago we showed that a former Microsoft engineer working on Windows BitLocker confirmed that the US government asks Microsoft for back doors and now we have more details on how this is done, courtesy of cryptology enthusiasts in Cryptome:
Microsoft OneDrive in NSA PRISM
1) Bitlocker keys are uploaded to OneDrive by ‘device encryption’.
“Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected.
If the device is not domain-joined a Microsoft Account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to online Microsoft account and TPM protector is created.”
2) Device encryption is supported by Bitlocker for all SKUs that support connected standby. This would include Windows phones.
“BitLocker provides support for device encryption on x86 and x64-based computers with a TPM that supports connected stand-by. Previously this form of encryption was only available on Windows RT devices.”
3) The tech media and feature articles recognise this.
“… because the recovery key is automatically stored in SkyDrive for you.”
4) Here’s how to recover your key from Sky/OneDrive.
“Your Microsoft account online. This option is only available on non-domain-joined PCs. To get your recovery key, go to …onedrive.com…”
5) SkyDrive (now named OneDrive) is onboarded to PRISM. (pg 26/27)
When Microsoft speaks about security it usually means “national security”, i.e. the ability of the state to break security of software. It’s about interception, not security. When Microsoft speaks about ‘secure boot’ it speaks about an antifeature in UEFI that enables the state to remotely brick computers, too.
The sad thing is that amid many BSD milestones as of recently (FreeBSD, OpenBSD, PC-BSD and others) there are those who fall for the false promise of UEFI, which does more harm than good to security. OpenBSD, which takes security very seriously, has already blasted UEFI 'secure boot' and blasted those who support it (including Red Hat), whereas FreeBSD got bamboozled into UEFI 'secure boot' and with it, the FreeBSD-derived PC-BSD gets bamboozled too:
Marking the twenty-first birthday of FreeBSD was the release of FreeBSD 10.1-RC4 and separately was the FreeBSD-derived PC-BSD 10.1 RC2 release.
FreeBSD 10.1-RC4 is expected to be the final RC build of FreeBSD 10.1 and brought fixes for ATA CF ERASE breakage and a race fix that could cause an EPT misconfiguration VM-exit.
More details on FreeBSD 10.1-RC4 can be found via its Sunday release announcement. The official release of FreeBSD 10.1 is now hopefully a few days out with its many new features and changes.
This is not a good idea at all. PC-BSD needs to follow the example set by OpenBSD, not FreeBSD (with its codebase). It sure starts looking like not only Microsoft but Red Hat too is bending over to its lucrative clients and contracts with the Deep State. Based on established observations from one decade ago, including more recent developments that Red Hat refuses to comment on, it seems possible that back doors in encryption (by default) is the de facto standard among large corporations. When they speak about “security” there must be fine prints and they’re omitted from the advertising. At risk of breaking the silence about
systemd (because we don’t want to inflame ‘civil wars’),
systemd replaces/obviates so much highly mature software that it certainly increases the likelihood of bug doors being introduced in RHEL/Red Hat (
systemd‘s patron) and by extension/inheritance many other distributions of GNU/Linux. █