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.
GNU tools are required to have a usable system
How so? These reddit users find BusyBox/Linux usable. It's what you get when you replace glibc with uClibc, Newlib, or Bionic, and then drop Bash and Coreutils (GPL) in favor of BusyBox (also GPL, but not part of GNU).
the need for the GNU Compiler Collection to compile the kernel
Clang has been compiling Linux for seven years.
In most of the world, highly secure windows mean 1/2" to 3/4" steel bars...
I don't see a helluva lot of flamebait in the summary. MS releasing security standards that are legitimate is actual news and deserves legitimate consideration. The ridiculousness of the standard "M$=bad" bullshit responses doesn't help anyone and make things better for computing in general. Simply saying that (not saying you do, using "you" as a generalization) "you use Linux and everyone else should to" simply shows that you have no grounding in pragmatic reality.
Only free software (software the user is free to run, inspect, share, and modify) can be assessed for security, fixed or improved, shared (even commercially), and run at any time for any reason. Without software freedom you're not being treated ethically and you deserve full control over your computers.
Nonfree software is never trustworthy, no matter how long you've run it, how much you're used to its interface, or how much you feel like you can trust it. You have no idea what nonfree software is doing when it runs, you have no permission to alter it, share it, or inspect it no matter how technical and willing you are to do these things. You might not even have permission to run it anytime you want for any reason.
So there is no way to secure Windows 10 so long as Windows 10 is nonfree software. The same applies to any other nonfree software too. No amount of public relations changes how computers and software work.
Digital Citizen
The chances of it coming with a version of windows that doesn't send any data back home to mama is pretty much nil.
It should be able to download security patches without sending any identifying information, tell you when it wants to do it, and be highly selective about what it does download from windows update servers.
But if my system isn't sending back any data, how will Microsoft know when to phone me and tell me when they've found viruses on my computer?
:/
It's so helpful when that nice foreign sounding gentleman calls me to help me get everything fixed up..... which reminds me.. I hope he rings again soon, after the last time, I don't seem to be able to log into my email or Bitcoin wallet
This is not about security: this is about locking down the system to a vendor. It's right there in TFS:
...trusted platform modules (TPM), platform boot verification... UEFI 2.4 or later, Secure Boot, Secure MOR 2 or later, and support the Windows UEFI Firmware Capsule Update specification.
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.
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