Privacy Respecting Laptops

Blibbet blibbet at gmail.com
Mon Sep 14 15:51:47 PDT 2015


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.




More information about the cypherpunks mailing list