←back to thread

I read the federal government’s Zero-Trust Memo so you don’t have to

(www.bastionzero.com)
656 points EthanHeilman | 5 comments | 27 Jan 22 15:06 UTC | HN request time: 0.25s | source
Show context
staticassertion ◴[27 Jan 22 15:56 UTC] No.30102061[source]▶
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.

1. No more SMS and TOTP. FIDO2 tokens only.

2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.

3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

replies(15): >>30103088 #>>30103131 #>>30103846 #>>30104022 #>>30104121 #>>30104716 #>>30104840 #>>30105344 #>>30106941 #>>30107798 #>>30108481 #>>30108567 #>>30108916 #>>30111757 #>>30112413 #
c0l0 ◴[27 Jan 22 18:23 UTC] No.30104121[source]▶
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

replies(16): >>30104148 #>>30104166 #>>30104241 #>>30104603 #>>30105136 #>>30106352 #>>30106792 #>>30107048 #>>30107250 #>>30107515 #>>30108070 #>>30108409 #>>30108716 #>>30108754 #>>30109550 #>>30123243 #
1. pabs3 ◴[27 Jan 22 23:50 UTC] No.30108754[source]▶
Identical source code when recompiled should produce identical binaries:

https://reproducible-builds.org/

Agreed that people should have the freedom to modify their software though.

replies(1): >>30111538 #
2. thinkmassive ◴[28 Jan 22 07:07 UTC] No.30111538[source]▶
A remote cryptographically-signed attestation is not reproducible

https://developer.android.com/training/safetynet/attestation

replies(3): >>30112204 #>>30123320 #>>30123508 #
3. ◴[28 Jan 22 08:45 UTC] No.30112204[source]▶
4. rstuart4133 ◴[29 Jan 22 02:53 UTC] No.30123320[source]▶
> A remote cryptographically-signed attestation is not reproducible

No one wants to reproduce an attestation. If you could, it could be copied, and if you can copy an attestation any hardware could send it to prove it was something else - something the other end trusts, rendering is useless for it's intended purpose.

However, the attestation is attesting the hardware you are running on is indeed "reproduced", as in it is a reliable copy of something the other end trusts. It could be a device from Yubi Key and in effect you are trusting Yubi Corp's word on the matter. Or, it could be an open source design everybody can inspect, reproducibly rendered in hardware and firmware. Personally, I think trusting the former is madness, as is trusting the latter without a reproducible build.

5. pabs3 ◴[29 Jan 22 03:31 UTC] No.30123508[source]▶
I don't know much about attestation, but the repro builds folks have an approach for dealing with signatures; you build once, then copy the signature into the source, so that as long as the unsigned build result is bit-identical, the signatures still match and anyone can reproduce the signed build result.

https://reproducible-builds.org/docs/embedded-signatures/