Slashdot Mirror
Microsoft Releases Standards For Highly Secure Windows 10 Devices (bleepingcomputer.com)
An anonymous reader writes from a report via BleepingComputer: Yesterday, Microsoft released new standards that consumers should follow in order to have a highly secure Windows 10 device. These standards include the type of hardware that should be included with Windows 10 systems and the minimum firmware features. The hardware standards are broken up into 6 categories, which are minimum specs for processor generation, processor architecture, virtualization, trusted platform modules (TPM), platform boot verification, and RAM. Similarly, firmware features should support at least UEFI 2.4 or later, Secure Boot, Secure MOR 2 or later, and support the Windows UEFI Firmware Capsule Update specification.
The PR=B$ messaging secure for you, the corporate reality, secure from you. M$ securing your PC from you, compulsory software installs even firm ware upgrades, that cannot be refused. Each and every log in to the server that controls your PC capable of altering all configurations to what ever M$ corporate demands and that includes, deleting files off your computer or even bricking you computer. M$ securing your computer from you and they mean it, fuck you, you install Windows, they own your computer and your digital life, learn to pay rent fuckers or else.
Chaos - everything, everywhere, everywhen
"Highly", "secure", "windows". I've heard those words before but never in the same sentence.
Which raises the question "Secure for Whom?".
If you want a secure system, look at OpenVMS.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Every post I see so far is the generic: see Windows in the title, bash Windows in comments.
Fair enough.
The processor architecture requirement is to have a 64-bit processor so that Windows can take advantage of VBS, or Virtualization-based security, which uses the Windows hypervisor.
The idea of using hypervisors rather than operating systems for isolation is both sad and absolutely necessary. What should happen is the operating system should provide these services in a tractably verifiably secure manner. Since that seems to be practically impossible at the moment the hypervisor is the only game in town.
Highly secured Windows 10 devices should support Intel VT-d, AMD-Vi, or ARM64 SMMUs in order to take advantage of Input-Output Memory Management Unit (IOMMU) device virtualization
Not a chance in hell so long as Intel AMT exists. While I agree MMUs are necessary for security they are currently a massive enabler of insecurity.
Another recommended component is a Trusted Platform Module, or TPM â" a hardware module that is either integrated into a computer chipset or can be purchased as a separate module for supported motherboards that handles the secure generation of cryptographic keys, their storage, a secure random number generator, and hardware authentication.
I don't like TPM because if it breaks everything it protects is gone and I neither need nor want my systems to be secured against physical access in a way that can't stand alone. (e.g. passphrase)
In addition, Microsoft recommends platform boot verification, which is a feature that prevents the computer from loading a firmware that was not designed by the system manufacturer. This prevents attackers from uploading a malicious or compromised firmware to the computer.
I have always hated the idea of using complex cryptography guarded by keys that are bound to be compromised with global repercussions. It's a massive house of cards that seems more and more likely to fail as the profit motive for it's compromise increases.
There is a much easier way to protect operating systems from persistent threats.
1. Forbid all hardware from physically possessing any means of self-contained persistent field upgradability. All necessary firmware updates must be loaded during or after boot and they must not survive a reboot.
2. Provide an option for protected storage area the operating system boots from and is then hardware fused to read only prior to becoming available to the end user until next reboot when the process repeats.
This has the following advantages over secure boot.
1. Easier to implement.
2. Future proof, no worries about protecting crypto from unforeseeable threats.
3. Offers maximal flexibility since the OS gets to decide when to blow the fuse it can trade safety for convenience per OS preferences and whims of the end user as allowed by OS.
4. This is more secure because it does not depend on thousands of companies guarding secrets (encryption keys) that have a history of being stolen and prove difficult to practically recall. Also secure boot requires that all signed drivers that can be loaded remain secure against compromise... The attack surface is simply too big to practically address.
5. System can not be misused to deny owners of computing hardware access to load their own systems. Users always retain full control over what operating systems get loaded into the protected area.
Words like "trusted", "secure" etc in computer salesdroid-speak are like "people's" and "democratic" when they get shoe-horned into a country's name - they're a warning sign, a veneer to hide a darker truth.
Trusted, as a technical term, means exactly what you'd expect from its use as a non-technical term: it is a thing which is expected to be correct and which can compromise (at least part of) the system if not. It is not the same as trustworthy. For example, the trusted computing base is the set of all things (microcode, bootloader, firmware, kernel, privileged daemons) that must be correct for the system to be secure. A system that uses a formally verified microkernel to provide isolation has a component that is both trusted and trustworthy.
Secure in this context also means what you'd expect. A system supporting secure boot can only boot an OS (or, at least, a second-stage bootloader) that is signed by a trusted party. There's nothing stopping such a system from allowing you to provide your own public keys, and many do, but if malware corrupts your on-disk kernel image then the system will refuse to boot unless you've also installed the malware vendor's key.
There's always a tension between user freedom and security, which goes right back to Stallman complaining about users on shared systems not being given the root password: was it better to allow users of the system to fix issues even at the expense of making all of their files wide open to every other user of the system? In the MIT AI lab, it was probably fine for everyone to have the root password, but it's not fine for everyone on the Internet to have my root password.
I am TheRaven on Soylent News