On 09/14/2015 10:29 AM, oshwm wrote:
Maybe manufacturers aren't sure what they should be building in order to genuinely and honestly be able to market as 'Respects Your Privacy'. It sounds simple but when you look at the ultimate level of privacy protection then you are talking about open source hardware, software and manufacturing processes and proper auditing of all of these. For a company to manufacture and market a device under these conditions is likely to be hideously expensive and have a very small customer base who are willing to pay such a large price in cash terms. What might be a good idea is for a community such as this one to create some sort of scale which describes the methods, materials and processes to achieve some sort of scoring which would range from 'NSA Spying Device' (0 out of 10) to 'Complete Privacy Protection' (10 out of 10). This would then allow manufacturers to work to a specific score and advertise as such.
I agree, the FSF RSF program could do more to work OEMs/IHVs and get the message out about their program. But while GPL/GNU platform is nice, RMS doesn't seem to care for Open Source Hardware, just Free Software, so I'm not sure FSF RSF program can be the only source of guidance for OEMs/IHVs. FSF has nearly no specific OEM/IHV advice for "Free Hardware". Except to make it GPLv3. It seems to me that OSHWA doesn't seem to focus on firmware, nor -- it seems to me -- much for business systems. The other open hardware group also doesn't seem to doing much in this area. Today, the main org focusing on 'open hardware' for enterprise systems appears to be Open Compute Project, which is currently a UEFI-centric project. No citizen-centric, privacy+security-centric profile in OCP. I agree, FOSS OS vendors -- Linux Foundation, FreeBSD Foundation, etc. -- should offer some advise to OEMs/IHVs/IBVs as to how to build a decent Linux/BSD-friendly BIOS. Including things like "declarative ACPI", eg, no WBPT tables with Windows binaries in them, other Windows-centric ACPI tables that Linux/BSD doesn't use. The other day on a linaro or edk2 list, some engineers from Red Hat were talking about their decision for what to do with ACPI for Linux for a particular table. This should be thought out for all modern ACPI tables. As well as SecureBoot OS defaults and MSFT keys, and use of coreboot or U-Boot instead of UEFI, in some cases. A list of ARM and Intel and AMD features that can be removed or opted-out or not added, or not enabled, and what privacy/freedom and security case does it help/hinder would be nice. Requiring vendors to provide a changelog, list of all modules/payloads/drivers embedded in firmware image, along with OSCP/CRL URLs for signed code verification. Right now, most people don't know what features their firmware has. Pre-sales data technical data from OEMs/IHVs is terrible w/r/t firmware, they only cover hardware and software. What tools to include or not include in silicon/firmware, like Absolute.com's Persistence, or remote management software (including IPMI, Redfish, DASH/SMASH, etc.) Re: classifications, for UEFI, there already are 3 classes of systems, BIOS-only, hybid BIOS/UEFI, and UEFI-only. UEFI aside, there is TCG Measured Boot, Trused Boot, Solaris Verified Boot, Android Verified Boot, Chrome Verified Boot (Class A and Class B), U-Boot Verified Boot, and other security technologies. It would be nice to have some crypto research comparing the strengths of all modern secure/verified/trusted/measured/etc flavors of boots. And given how crypto is core to trust in most of these, some don't enable any way for user to verify trust, no CRL/OSCP URLs. We have to 'trust' that the firmware's CAs are not behaving like Diginotar. One consumer feature should be the ability to test all keys for validity. There are 3 NIST docs for BIOS recommendations for OEMS/IHVs/IBVs/OSVs for BIOS security: NIST SP800-147, SP800-147b, and SP800-155. NIST guidelines are rather abstract, no pragmatic best practices. The 147 Provisioning stage is something that, as I read the spec, is probably not something that most OEM systems today, especially not the 'golden master' extra level of security, which requires -- as I understand it -- full source to your firmware. There is also CommonCriteria/NSA/IAP BIOS Update Protection Profile (which no vendors meet, AFAIK). Nice read for BIOS attack model perspective. <http://www.niap-ccevs.org/pp/pp.cfm> None of the NIST/NSA docs refer to Intel CHIPSEC. UEFI Forum recommends Intel UEFI OEMs run CHIPSEC to test their systems for security. Hard to believe any enterprise sysadmins are following NIST firmware platform lifecycle model, if they don't know what tools to use. :-) Intel CHIPSEC only works on Intel systems, not x86 clones (AMD, etc.), so no similar firmware security tools for other systems. Linaro may port CHIPSEC to AArch64, they expressed an interest a few months ago, but nothing since then. And no interest, apparently, in AArch32. If no port, what other firmware vulnerability assessment tools are there? Intel CHIPSEC only works on new systems, no tests for older Intel systems. No CHIPSEC for Itanium, either. :-) Without tools that check for the latest vulnerabilities (i.e., the ones that security researchers talked about at last years' DEF CON), the systems won't be built securely. I presume we need more help from FSF, Linux Foundation, OSHWA, and other related orgs, to direct and concentrate 'crowd funding' for efforts to build new Free/Open Hardware (FOHW), like Bunnie has started doing. RMS blessed CrowdSupply as the official source of crowd funding. A baseband chip -- or some SDR equivalent -- for phones would be nice; IMO, OSMOCOMBB isn't progressing fast enough. For years, OEMs/IHVs got a lot of input from Microsoft. For each new OS release, MS had a spec for that year's Windows Desktop/Laptop PC and for the Windows Server PC. FOSS OS vendors, or other communities-of-interest (like privacy-centric cypherpunks) don't give OEMs/IHVs any advice. The Windows Hardware logo, and ability to license/sell Windows, is a great set of carrots. FOSS is free, so no license deals, but community could include a logo program with the guidelines. I'm not aware of much non-Windows advise to OEMs/IHVs like this, besides a few Linux Foundation programs (Carrier Grade Linux, etc.). And none that are updated each year with current hardware/bus/peripheral trends and updates defaults for memory or other new advise from last year (like VM advise after this year's DEF CON). Perhaps an annual award for vendors, to help motivate them, best and worst award. Bunnie wins and Lenovo loses this year, maybe Purism wins next year. As an example, the privacy-centric Italian-based group the "Winston Smith Project" has an annual award for best misuse of privacy by a vendor.