14 ms·

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 c0l0 5y ago

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/android/gms/safetynet/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.

seibelj 5y ago
Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero https://github.com/monero-project/monero
- nybble41 5y ago
  Reproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot (with a TPM), and in the context of a BYOD environment precludes the device owner having full control of their own hardware. Obviously this is not an issue if the organization only permits access to its services from devices it owns, but no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.
  - InitialLastName 5y ago
    > no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services. It seems like the sensible rule of thumb is: If your organization needs that level of control, it's on your organization to provide the device.
    - jacobr1 5y ago
      Or we could better adopt secure/confidential computing enclaves. This would allow the organization to have control over the silo'd apps and validate some degree of security (code tampering, memory encryption, etc) but not need to trust that other apps on the device or even the OS weren't compromised.
      - wizzwizz4 5y ago
        I'm uncomfortable letting organisations have control over the software that runs on my hardware. (Or, really, any hardware I'm compelled to use.) Suppose the course I've been studying for the past three years now uses $VideoService, but $VideoService uses remote attestation and gates the videos behind a retinal scan, ten distinct fingerprints, the last year's GPS history and the entire contents of my hard drive?¹ If I could spoof the traffic to $VideoService, I could get the video anyway, but every request is signed by the secure enclave. (I can't get the video off somebody else, because it uses the webcam to identify when a camera-like object is pointed at the screen. They can't bypass that, because of the remote attestation.) If I don't have ten fingers, and I'm required to scan ten fingerprints to continue, and I can't send fake data because my computer has betrayed me, what recourse is there? ¹: exaggeration; no real-world company has quite these requirements, to my knowledge
        jacobr1 5y ago
        So there are two levels of tradeoffs: 1) The requirements themselves. These are different for consumer vs employee type scenarios. So general, I'd prefer we err on the side of DRM free for things like media, but there are legitimate concerns around things like data privacy when you are an employee of an organization handling sensitive data. 2) Presuming there are legitimate reasons to have strong validation of the user and untampered software, we have the choice of A) using only organization supplied hardware in those case or B) using your own with some kind of restriction. I'd much prefer to use my own as much as possible ... if I can be ensured that it won't spy on me, or limit what I can do, for the non-organization specific purposes I've explicitly opted-in to enable. > I'm uncomfortable letting organisations have control over the software that runs on my hardware. I'm not, if we can sandbox. I'm fine with organizations running javascript in my browser for instance. Or running mobile apps that can access certain data with explicit permissions (like granting access to my photos so that I can share them in-app). I think we can do better with both more granular permissions, better UX, and cryptographic guarantees to both the user and the organization that both the computation and data is operating at the agreed level.
- c0l0 5y ago
  Let me elaborate on the problem I do have with remote attestation, no matter if I can verify that the signed binary is identical with something I can build on my own. I use LineageOS on my phone, and do not have Google Play Services installed. The phone only meaningfully interacts with a very few and most basic Google services, like an HTTP server for captive portal detection on Wifi networks, an NTP server for setting the clock, etc. All other "high-level" services that I am aware of, like Mail, Calendaring, Contacts, Phone, Instant Messaging, etc., are either provided by other parties that I feel more comfortable with, or that I actually host myself. Now let's assume that I would want or have to do online/mobile banking on my phone - that will generally only work with the proprietary app my bank provides me with. Even if I choose to install their unmodified APK, (any lack of) SafetyNet will not attest my LineageOS-powered phone as "kosher" (or "safe and secure", or "healthy", or whatever Google prefers calling it these days), and might refuse to work. As a consequence, I'm effectively unable to interact via the remote service provided by my bank, because they believe they've got to protect me from the OS/firmware build that I personally chose to use. Sure, "just access their website via the browser, and do your banking on their website instead!", you might say, and you'd be right for now. But with remote attestation broadly available, what prevents anyone from also using that for the browser app on my phone, esp. since browser security is deemed so critical these days? I happen to use Firefox from F-Droid, and I doubt any hypothetical future SafetyNet attestation routine will have it pass with the same flying colors that Google's own Chrome from the Play Store would. I'm also certain that "Honest c0l0's Own Build of Firefox for Android" wouldn't get the SafetyNet seal of approval either, and with that I'd be effectively shut off from interacting with my bank account from my mobile phone altogether. The only option I'd have is to revert back to a "trusted", "healthy" phone with a manufacturer-provided bootloader, firmware image, and the mandatory selection of factory-installed, non-removable crapware that I am never going to use and/or (personally) trust that's probably exfiltrating my personal data to some unknown third parties, sanctified by some few hundreds of pages of EULA and "Privacy" Policy. With app stores on all mainstream and commercially successful desktop OSes, the recent Windows 11 "security and safety"-related "advances" Microsoft introduced by (as of today, apparently still mildly) requiring TPM support, and supplying manufacturers with "secure enclave"-style add-on chips of their own design ("Pluton", see https://www.techradar.com/news/microsofts-new-security-chip-is-coming-to-keep-amd-laptops-safe https://www.techradar.com/news/microsofts-new-security-chip-...), I can see this happening to desktop computing as well. Then I can probably still compile all the software I want on my admittedly fringe GNU/Linux system (or let the Debian project compile it for me), but it won't matter much - because any interaction with the "real" part of the world online that isn't made by and for software freedom enthusiasts/zealots will refuse to interact with the non-allowlisted software builds on my machine. It's going to be the future NoTCPA et al. used to combat in the early 00s, and I really do dread it.
- chaxor 5y ago
  Wow, the monero project looks like they have some great ideas. I like this reproducible build - may try to get my team to work towards that. It seems like monero has more of a focus on use as a real currency, so hopefully it isn't drawing in the speculative people and maintains it's real use.
Signez 5y ago
Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement. Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation or whatever."
- deleted 5y ago
  [deleted]
- dathinab 5y ago
  If something like that is good enough to fulfill the requirements, that would be good. Some services already thinks like that, like I think discord.
- hansvm 5y ago
  Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.
  - freedomben 5y ago
    It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what it is. We've emailed you a code to the email account that you are also locked out of because something is a tiny bit different with you. Also we're putting a flag on your account so it raises holy hell the next 36 times you log in."
    - sciurus 5y ago
      Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.
reginaldo 5y ago
It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.
- kelnos 5y ago
  It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.
  - ethbr0 5y ago
    The clearer way to put this is: when faced with a regulatory requirement, most of the market will choose whatever pre-packaged solution most easily satisfies the requirement. In the case of client attestation, this is how we get "Let Google/Apple/Microsoft handle that, and use what they produce." And as a end state, leads to a world where large, for-profit companies provide the only whitelisted solutions, because they're the largest user bases and offer a turn-key feature, and the market doesn't want to do addition custom work to support alternatives.
    - withinboredom 5y ago
      In my experience, it isn’t that companies don’t want to put in the work, it’s that some middle manager made a decision. I’ve been told to “implement login with X” more than once in my career and when asked what about Y or Z, they say, “we only want X” with no further explanation.
  - bigiain 5y ago
    I’m not even so sure I’m totally against banks doing that either. From where I sit right now, I have within arms reach my MacBook, a Win11 Thinkpad, a half a dozen Raspberry Pis (including a 400), 2 iPhones only one of which is rooted, an iPad (unrooted) a Pinebook, a Pine Phone, and 4 Samsung phones one with its stock Android7 EOLed final update and three rooted/jailbroken with various Lineage versions. I have way way more devices running open source OSen than unmolested Apple/Microsoft/Google(+Samsung) provided Software. My unrooted iPhone is the only one of them I trust to have my banking app/creds on. I’d be a bit pissed if Netflix took my money but didn’t run where I wanted it, but they might be already, I only ever really use it on my AppleTV and my iPad. I expect I’d be able to use it on my MacBook and thinkpad, but could be disappointed, I’d be a bit surprised if it ran on any of my other devices listed…
shadowgovt 5y ago
> If only specific builds of software that are on a vendor-sanctioned allowlist Yes, but for government software this is a bog-standard approach. Not even "the source code is publicly viewable to everyone" is sufficient scrutiny to pass government security muster; specific code is what gets cleared, and modifications to that code must also be cleared.
tablespoon 5y ago
>> 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. > 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. Is that really a problem? In practice wouldn't it just mean you can only use employer-provided and certified devices? If they want to provide their employees some Free Software-based client system, that configuration would be on the whitelist.
- shbooms 5y ago
  I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If your employer forces you to, say, only use a certain version of Windows as your OS in order to do your job, that's generally acceptable to most people. But if your TV streaming provider tells you have to use a certain version of Windows to consume their product, that's not considered acceptable to a good deal of people.
  - btbuilder 5y ago
    I think browser-based streaming is the only scenario impacted. Apps can already interrogate their platform and make play/no play decisions. They are also already limiting (weakly) the max number of devices that can playback which requires some level of device identification, just not at the confidence required for authentication.
    - dathinab 5y ago
      Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by not allowing you to control the device you own.
wyldfire 5y ago
> I think 3. is very harmful for actual, real-world use of Free Software. It has been a long, slow but steady march in this direction for a while [1]. Eventually we will also bind all network traffic to the individual human(s) responsible. 'Unlicensed' computers will be relics of the past. [1] https://boingboing.net/2012/01/10/lockdown.html https://boingboing.net/2012/01/10/lockdown.html
- enriquto 5y ago
  The dystopia described in Stallman's "The right to read" is almost here... and we don't even get to colonize the solar system.
- deleted 5y ago
  [deleted]
nonameiguess 5y ago
In practice, the DoD right now uses something called AppGate, which downloads a script on-demand to check for device compliance, and it supports free software distributions, but the script isn't super sophisticated and relies heavily on being able to detect the OS flavor and assumes you're using the blessed package manager, so right now it only works for Debian and RedHat descended Linux flavors. It basically just goes down a checklist of STIG guidelines where they are practical to actually check, and doesn't go anywhere near the level of expecting you to have a signed bootloader and a TPM or checking that all of the binaries on your device have been signed.
alksjdalkj 5y ago
Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some point and figure out what they want to do about it.
- lupire 5y ago
  Free software doesn't really work in a networked untrusted world.
  - tomrod 5y ago
    Why?
  - nijave 5y ago
    Linux and BSD beg to differ
- pdonis 5y ago
  > Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. No, it isn't. It's a way for corporations and governments to restrict what people can do with their devices. That makes sense if you're an employee of the corporation or the government, since organizations can reasonably expect to restrict what their employees can do with devices they use for work, and I would be fine with using a separate device for my work than for my personal computing (in fact that's what I do now). But many scenarios are not like that: for example, me connecting with my bank's website. It's not reasonable or realistic to expect that to be limited to a limited set of pre-approved software. The correct way to deal with untrusted software on the client is to just...not trust the software on the client. Which means you need to verify the user by some means that does not require trusting the software on the client. That is perfectly in line with the "zero trust" model advocated by this memo.
- 5y ago
reilly3000 5y ago
How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client. If you want to get a package that is in the Arch core/ repo, doesnt that require a form of attestation? I just don’t see a slippery slope towards dropping support for unofficial clients, we’re already at the bottom where they are generally and actively rejected for various reasons. Still, the Android case is admittedly disturbing, it feels a lot more personal to be forced to use certain OS builds; that goes beyond the scope of how I would define a client.
- pishpash 5y ago
  Where we "already" are is not a state to be anchored on.
  - reilly3000 5y ago
    That’s fair. Its just to say there is a lot of context for client verification in software. Competitive multiplayer gaming has become an arms races of exploits and invasive anti-cheat measures; there is no concept of bring-your-own-client when there is money on the line. Valve has taken a less heavy-handed approach and let users have more freedom over their client and UI, but they also have a massive bot problem in titles like TF2. I can’t connect to my work network from a random client, and it will throw flags and eventually block me if I connect with an out-of-date OS version. I can’t present any piece of paper with my banking data and a signature on it and expect other parties to accept it. I have to present it on an authorized document. I guess money may be the common denominator here.
- worthless-trash 5y ago
  > How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client. This depends on how far down the rabbit hole you want to go, if it was secureboot, only signed processes can run, would that make you feel better ? If it doesn't.. what would ?
lupire 5y ago
"Software freedom" doesn't really make sense when the software's function is "using someone else's software". You're stil at the mercy of the server (which is why remote attestation is even interesting in the first place). If you want to use free software, only commect to Affero GPL servces and don't use nonfree services, and don't consume nonfree content.
- wizzwizz4 5y ago
  You're usually only at the mercy of the server because you don't control the client; a free YouTube client like VLC remains useful. A free Microsoft Teams client would be useful. I allege that free VNC clients are also useful, even if there's non-free software on the other end.
no_time 5y ago
>Remote attestation really is killing practical software freedom. Which will continue marching forward without pro-user legislation. Which is extraordinarly unlikely to happen since the government has vested interest in this development.
- 0xedd 5y ago
  *in the US. Luckily, it's a dwindling power and Europe fights and penalizes large organizations breaching market "morals".
lmeyerov 5y ago
Yep I'd feel 100% differently about this stuff if the NSA or some other cybersecurity gov arm making these rules used their massive cybersecurity budgets to provide free MFA, TLS, encrypted DNS, etc., whether US gov hosted or via non-profit (?) partners like LetsEncrypt. OSS & free software otherwise has a huge vendor tax to actually get used. As is, this feels like economic insecurity & anti-competition via continued centralization to a small number of megavendors. Rules like this should come with money, and not to primes & incumbents, but utility providers. Sure, our team is internally investing in building out a lot of this stuff, but we have security devs & experience, while the long tail of software folks use doesn't. The gov sets aside so much $$$$ for the perpetual cyber war going on, but not for simple universal basics here :(
notatoad 5y ago
If you can argue that remote attestation doesn't provide additional security, then i'd love to hear that argument. but it seems like a fairly clear-cut case that it does provide additional security, and i don't think it's reasonable to accept a lower level of security for the sake of allowing unverified builds of open-source software. there are specific contexts where you want to distribute information as widely as possible, and in those contexts it makes sense to allow any software versions to access the information. but for contexts where security is important, that means verifying the client software isn't compromised.
- curmudgeon81 5y ago
  A server rate limiting login attempts is additional security. A remote system asked to promise it's what it says it is: the illusion of security. Jailbreaking, DRM, etc are all evidence of this illusion.
- nijave 5y ago
  It can go pretty terribly sideways just like antivirus with poorly coded, proprietary, privileged agents running on end user devices collecting data. I worked at a place that only allowed "verified" software before and it's an ongoing battle to keep that list updated. Things like digital signatures can be pretty reliable but if you're version pinning you can make it extremely difficult to quickly adopt patched versions when a vulnerability comes out.
pabs3 5y ago
Identical source code when recompiled should produce identical binaries: https://reproducible-builds.org/ https://reproducible-builds.org/ Agreed that people should have the freedom to modify their software though.
- thinkmassive 5y ago
  A remote cryptographically-signed attestation is not reproducible https://developer.android.com/training/safetynet/attestation https://developer.android.com/training/safetynet/attestation
  - deleted 5y ago
    [deleted]
  - rstuart4133 5y ago
    > 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.
  - pabs3 5y ago
    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/ https://reproducible-builds.org/docs/embedded-signatures/
staticassertion 5y ago
I wish I had responded earlier, because now this entire thread is full of nonsense and I can't really respond to everything. But attestation can mean a lot of things and isn't inherently in conflict with free software. For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Free software would only, in theory, need a digital signature so that we could add that to our allowlist.
- nybble41 5y ago
  > For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Presumably (hopefully) these are corporate-owned devices, with a policy like that. Remote attestation is fine if it's controlled by the device's owner, and you can certainly run free software on such a device, if that particular build of the software has been "blessed" by the corporation. However, the user doesn't get the freedoms which are supposed to come with free software; in particular, they can't build and run a modified version without first obtaining someone else's approval. At the very least it suggests a certain lack of respect for your employees to lock down the tools they are required to use for their job to this extent.
rstuart4133 5y ago
> I think 3. is very harmful for actual, real-world use of Free Software. I hold the reverse view. The only security token I'd trust is the only thing that isn't open is the private keys the device generates when you press the reset button. The rest meaning from the CPU up (say RISC-V) and the firmware must be open to inspection by anybody. In fact, it should also be easy to peel away the silicon protection so you can see everything bar the cells storing the private keys. The other non-negotiable is the thing that computes and transmits the "measures" of the system being attested to (including it’s own firmware) can not be changed - meaning no stinking "security" patches are allowed at that level. If it's found broken, throw it away as the attestation is useless. The attestation then becomes the device you hold is faithful rendering / compiling of open source design document X by open source compiler Y. And I can prove that myself, by doing building X using Y and verifying the end result looks like the device I hold. This process is also known as reproducible builds. What we have now (eg, YubiKeys) is not that. Therefore I have to trust Yubi Corp. To see what that's a problem, see the title of this story. It has the words "Zero-Trust" in it. In reality of course there is no such thing as "Zero-Trust". I will never be able to verify everything myself, ergo I have to trust something. The point is there is a world of difference between trusting an opaque black box like Yubi Corp, and trusting an open source reproducible build, where a cast of random thousands can crawl over it and say, "it seems OK to me". In reality it's not the ones that say "it seems OK" you are trusting. You are trusting the mass media (places like this in other words), to pick up and amplify the one voice among millions that says "I've found a bug - and because it's open I can prove it" so everyone hears it. So to me it looks to be the reverse of what you say. Remote attestation won't kill software freedom. Remote attestation, done in a way that we can trust, must be built using open source. Anything less simply won’t work.

by c0l0 5y ago

seibelj 5y ago

Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero https://github.com/monero-project/monero

nybble41 5y ago
Reproducible builds allow the user of the software to verify the version that they are using or installing. They do not, by themselves, allow the sort of remote attestation which would permit a service to verify the context for authentication—the user, or a malicious actor, could simply modify the device to lie about the software being run. Secure attestation about device state requires something akin to Secure Boot (with a TPM), and in the context of a BYOD environment precludes the device owner having full control of their own hardware. Obviously this is not an issue if the organization only permits access to its services from devices it owns, but no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services.
- InitialLastName 5y ago
  > no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services. It seems like the sensible rule of thumb is: If your organization needs that level of control, it's on your organization to provide the device.
  - jacobr1 5y ago
    Or we could better adopt secure/confidential computing enclaves. This would allow the organization to have control over the silo'd apps and validate some degree of security (code tampering, memory encryption, etc) but not need to trust that other apps on the device or even the OS weren't compromised.
    - wizzwizz4 5y ago
      I'm uncomfortable letting organisations have control over the software that runs on my hardware. (Or, really, any hardware I'm compelled to use.) Suppose the course I've been studying for the past three years now uses $VideoService, but $VideoService uses remote attestation and gates the videos behind a retinal scan, ten distinct fingerprints, the last year's GPS history and the entire contents of my hard drive?¹ If I could spoof the traffic to $VideoService, I could get the video anyway, but every request is signed by the secure enclave. (I can't get the video off somebody else, because it uses the webcam to identify when a camera-like object is pointed at the screen. They can't bypass that, because of the remote attestation.) If I don't have ten fingers, and I'm required to scan ten fingerprints to continue, and I can't send fake data because my computer has betrayed me, what recourse is there? ¹: exaggeration; no real-world company has quite these requirements, to my knowledge
      - jacobr1 5y ago
        So there are two levels of tradeoffs: 1) The requirements themselves. These are different for consumer vs employee type scenarios. So general, I'd prefer we err on the side of DRM free for things like media, but there are legitimate concerns around things like data privacy when you are an employee of an organization handling sensitive data. 2) Presuming there are legitimate reasons to have strong validation of the user and untampered software, we have the choice of A) using only organization supplied hardware in those case or B) using your own with some kind of restriction. I'd much prefer to use my own as much as possible ... if I can be ensured that it won't spy on me, or limit what I can do, for the non-organization specific purposes I've explicitly opted-in to enable. > I'm uncomfortable letting organisations have control over the software that runs on my hardware. I'm not, if we can sandbox. I'm fine with organizations running javascript in my browser for instance. Or running mobile apps that can access certain data with explicit permissions (like granting access to my photos so that I can share them in-app). I think we can do better with both more granular permissions, better UX, and cryptographic guarantees to both the user and the organization that both the computation and data is operating at the agreed level.
c0l0 5y ago
Let me elaborate on the problem I do have with remote attestation, no matter if I can verify that the signed binary is identical with something I can build on my own. I use LineageOS on my phone, and do not have Google Play Services installed. The phone only meaningfully interacts with a very few and most basic Google services, like an HTTP server for captive portal detection on Wifi networks, an NTP server for setting the clock, etc. All other "high-level" services that I am aware of, like Mail, Calendaring, Contacts, Phone, Instant Messaging, etc., are either provided by other parties that I feel more comfortable with, or that I actually host myself. Now let's assume that I would want or have to do online/mobile banking on my phone - that will generally only work with the proprietary app my bank provides me with. Even if I choose to install their unmodified APK, (any lack of) SafetyNet will not attest my LineageOS-powered phone as "kosher" (or "safe and secure", or "healthy", or whatever Google prefers calling it these days), and might refuse to work. As a consequence, I'm effectively unable to interact via the remote service provided by my bank, because they believe they've got to protect me from the OS/firmware build that I personally chose to use. Sure, "just access their website via the browser, and do your banking on their website instead!", you might say, and you'd be right for now. But with remote attestation broadly available, what prevents anyone from also using that for the browser app on my phone, esp. since browser security is deemed so critical these days? I happen to use Firefox from F-Droid, and I doubt any hypothetical future SafetyNet attestation routine will have it pass with the same flying colors that Google's own Chrome from the Play Store would. I'm also certain that "Honest c0l0's Own Build of Firefox for Android" wouldn't get the SafetyNet seal of approval either, and with that I'd be effectively shut off from interacting with my bank account from my mobile phone altogether. The only option I'd have is to revert back to a "trusted", "healthy" phone with a manufacturer-provided bootloader, firmware image, and the mandatory selection of factory-installed, non-removable crapware that I am never going to use and/or (personally) trust that's probably exfiltrating my personal data to some unknown third parties, sanctified by some few hundreds of pages of EULA and "Privacy" Policy. With app stores on all mainstream and commercially successful desktop OSes, the recent Windows 11 "security and safety"-related "advances" Microsoft introduced by (as of today, apparently still mildly) requiring TPM support, and supplying manufacturers with "secure enclave"-style add-on chips of their own design ("Pluton", see https://www.techradar.com/news/microsofts-new-security-chip-is-coming-to-keep-amd-laptops-safe https://www.techradar.com/news/microsofts-new-security-chip-...), I can see this happening to desktop computing as well. Then I can probably still compile all the software I want on my admittedly fringe GNU/Linux system (or let the Debian project compile it for me), but it won't matter much - because any interaction with the "real" part of the world online that isn't made by and for software freedom enthusiasts/zealots will refuse to interact with the non-allowlisted software builds on my machine. It's going to be the future NoTCPA et al. used to combat in the early 00s, and I really do dread it.
chaxor 5y ago
Wow, the monero project looks like they have some great ideas. I like this reproducible build - may try to get my team to work towards that. It seems like monero has more of a focus on use as a real currency, so hopefully it isn't drawing in the speculative people and maintains it's real use.

Signez 5y ago

Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement. Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation or whatever."

deleted 5y ago
[deleted]
dathinab 5y ago
If something like that is good enough to fulfill the requirements, that would be good. Some services already thinks like that, like I think discord.
hansvm 5y ago
Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.
- freedomben 5y ago
  It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what it is. We've emailed you a code to the email account that you are also locked out of because something is a tiny bit different with you. Also we're putting a flag on your account so it raises holy hell the next 36 times you log in."
  - sciurus 5y ago
    Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

reginaldo 5y ago

It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.

kelnos 5y ago
It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.
- ethbr0 5y ago
  The clearer way to put this is: when faced with a regulatory requirement, most of the market will choose whatever pre-packaged solution most easily satisfies the requirement. In the case of client attestation, this is how we get "Let Google/Apple/Microsoft handle that, and use what they produce." And as a end state, leads to a world where large, for-profit companies provide the only whitelisted solutions, because they're the largest user bases and offer a turn-key feature, and the market doesn't want to do addition custom work to support alternatives.
  - withinboredom 5y ago
    In my experience, it isn’t that companies don’t want to put in the work, it’s that some middle manager made a decision. I’ve been told to “implement login with X” more than once in my career and when asked what about Y or Z, they say, “we only want X” with no further explanation.
- bigiain 5y ago
  I’m not even so sure I’m totally against banks doing that either. From where I sit right now, I have within arms reach my MacBook, a Win11 Thinkpad, a half a dozen Raspberry Pis (including a 400), 2 iPhones only one of which is rooted, an iPad (unrooted) a Pinebook, a Pine Phone, and 4 Samsung phones one with its stock Android7 EOLed final update and three rooted/jailbroken with various Lineage versions. I have way way more devices running open source OSen than unmolested Apple/Microsoft/Google(+Samsung) provided Software. My unrooted iPhone is the only one of them I trust to have my banking app/creds on. I’d be a bit pissed if Netflix took my money but didn’t run where I wanted it, but they might be already, I only ever really use it on my AppleTV and my iPad. I expect I’d be able to use it on my MacBook and thinkpad, but could be disappointed, I’d be a bit surprised if it ran on any of my other devices listed…

shadowgovt 5y ago

> If only specific builds of software that are on a vendor-sanctioned allowlist Yes, but for government software this is a bog-standard approach. Not even "the source code is publicly viewable to everyone" is sufficient scrutiny to pass government security muster; specific code is what gets cleared, and modifications to that code must also be cleared.

tablespoon 5y ago

>> 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. > 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. Is that really a problem? In practice wouldn't it just mean you can only use employer-provided and certified devices? If they want to provide their employees some Free Software-based client system, that configuration would be on the whitelist.

shbooms 5y ago
I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If your employer forces you to, say, only use a certain version of Windows as your OS in order to do your job, that's generally acceptable to most people. But if your TV streaming provider tells you have to use a certain version of Windows to consume their product, that's not considered acceptable to a good deal of people.
- btbuilder 5y ago
  I think browser-based streaming is the only scenario impacted. Apps can already interrogate their platform and make play/no play decisions. They are also already limiting (weakly) the max number of devices that can playback which requires some level of device identification, just not at the confidence required for authentication.
  - dathinab 5y ago
    Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by not allowing you to control the device you own.

wyldfire 5y ago

> I think 3. is very harmful for actual, real-world use of Free Software. It has been a long, slow but steady march in this direction for a while [1]. Eventually we will also bind all network traffic to the individual human(s) responsible. 'Unlicensed' computers will be relics of the past. [1] https://boingboing.net/2012/01/10/lockdown.html https://boingboing.net/2012/01/10/lockdown.html

enriquto 5y ago
The dystopia described in Stallman's "The right to read" is almost here... and we don't even get to colonize the solar system.
deleted 5y ago
[deleted]

nonameiguess 5y ago

In practice, the DoD right now uses something called AppGate, which downloads a script on-demand to check for device compliance, and it supports free software distributions, but the script isn't super sophisticated and relies heavily on being able to detect the OS flavor and assumes you're using the blessed package manager, so right now it only works for Debian and RedHat descended Linux flavors. It basically just goes down a checklist of STIG guidelines where they are practical to actually check, and doesn't go anywhere near the level of expecting you to have a signed bootloader and a TPM or checking that all of the binaries on your device have been signed.

alksjdalkj 5y ago

Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some point and figure out what they want to do about it.

lupire 5y ago
Free software doesn't really work in a networked untrusted world.
- tomrod 5y ago
  Why?
- nijave 5y ago
  Linux and BSD beg to differ
pdonis 5y ago
> Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. No, it isn't. It's a way for corporations and governments to restrict what people can do with their devices. That makes sense if you're an employee of the corporation or the government, since organizations can reasonably expect to restrict what their employees can do with devices they use for work, and I would be fine with using a separate device for my work than for my personal computing (in fact that's what I do now). But many scenarios are not like that: for example, me connecting with my bank's website. It's not reasonable or realistic to expect that to be limited to a limited set of pre-approved software. The correct way to deal with untrusted software on the client is to just...not trust the software on the client. Which means you need to verify the user by some means that does not require trusting the software on the client. That is perfectly in line with the "zero trust" model advocated by this memo.
5y ago

reilly3000 5y ago

How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client. If you want to get a package that is in the Arch core/ repo, doesnt that require a form of attestation? I just don’t see a slippery slope towards dropping support for unofficial clients, we’re already at the bottom where they are generally and actively rejected for various reasons. Still, the Android case is admittedly disturbing, it feels a lot more personal to be forced to use certain OS builds; that goes beyond the scope of how I would define a client.

pishpash 5y ago
Where we "already" are is not a state to be anchored on.
- reilly3000 5y ago
  That’s fair. Its just to say there is a lot of context for client verification in software. Competitive multiplayer gaming has become an arms races of exploits and invasive anti-cheat measures; there is no concept of bring-your-own-client when there is money on the line. Valve has taken a less heavy-handed approach and let users have more freedom over their client and UI, but they also have a massive bot problem in titles like TF2. I can’t connect to my work network from a random client, and it will throw flags and eventually block me if I connect with an out-of-date OS version. I can’t present any piece of paper with my banking data and a signature on it and expect other parties to accept it. I have to present it on an authorized document. I guess money may be the common denominator here.
worthless-trash 5y ago
> How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client. This depends on how far down the rabbit hole you want to go, if it was secureboot, only signed processes can run, would that make you feel better ? If it doesn't.. what would ?

lupire 5y ago

"Software freedom" doesn't really make sense when the software's function is "using someone else's software". You're stil at the mercy of the server (which is why remote attestation is even interesting in the first place). If you want to use free software, only commect to Affero GPL servces and don't use nonfree services, and don't consume nonfree content.

wizzwizz4 5y ago
You're usually only at the mercy of the server because you don't control the client; a free YouTube client like VLC remains useful. A free Microsoft Teams client would be useful. I allege that free VNC clients are also useful, even if there's non-free software on the other end.

no_time 5y ago

>Remote attestation really is killing practical software freedom. Which will continue marching forward without pro-user legislation. Which is extraordinarly unlikely to happen since the government has vested interest in this development.

0xedd 5y ago
*in the US. Luckily, it's a dwindling power and Europe fights and penalizes large organizations breaching market "morals".

lmeyerov 5y ago

Yep I'd feel 100% differently about this stuff if the NSA or some other cybersecurity gov arm making these rules used their massive cybersecurity budgets to provide free MFA, TLS, encrypted DNS, etc., whether US gov hosted or via non-profit (?) partners like LetsEncrypt. OSS & free software otherwise has a huge vendor tax to actually get used. As is, this feels like economic insecurity & anti-competition via continued centralization to a small number of megavendors. Rules like this should come with money, and not to primes & incumbents, but utility providers. Sure, our team is internally investing in building out a lot of this stuff, but we have security devs & experience, while the long tail of software folks use doesn't. The gov sets aside so much $$$$ for the perpetual cyber war going on, but not for simple universal basics here :(

notatoad 5y ago

If you can argue that remote attestation doesn't provide additional security, then i'd love to hear that argument. but it seems like a fairly clear-cut case that it does provide additional security, and i don't think it's reasonable to accept a lower level of security for the sake of allowing unverified builds of open-source software. there are specific contexts where you want to distribute information as widely as possible, and in those contexts it makes sense to allow any software versions to access the information. but for contexts where security is important, that means verifying the client software isn't compromised.

curmudgeon81 5y ago
A server rate limiting login attempts is additional security. A remote system asked to promise it's what it says it is: the illusion of security. Jailbreaking, DRM, etc are all evidence of this illusion.
nijave 5y ago
It can go pretty terribly sideways just like antivirus with poorly coded, proprietary, privileged agents running on end user devices collecting data. I worked at a place that only allowed "verified" software before and it's an ongoing battle to keep that list updated. Things like digital signatures can be pretty reliable but if you're version pinning you can make it extremely difficult to quickly adopt patched versions when a vulnerability comes out.

pabs3 5y ago

Identical source code when recompiled should produce identical binaries: https://reproducible-builds.org/ https://reproducible-builds.org/ Agreed that people should have the freedom to modify their software though.

thinkmassive 5y ago
A remote cryptographically-signed attestation is not reproducible https://developer.android.com/training/safetynet/attestation https://developer.android.com/training/safetynet/attestation
- deleted 5y ago
  [deleted]
- rstuart4133 5y ago
  > 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.
- pabs3 5y ago
  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/ https://reproducible-builds.org/docs/embedded-signatures/

staticassertion 5y ago

I wish I had responded earlier, because now this entire thread is full of nonsense and I can't really respond to everything. But attestation can mean a lot of things and isn't inherently in conflict with free software. For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Free software would only, in theory, need a digital signature so that we could add that to our allowlist.

nybble41 5y ago
> For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Presumably (hopefully) these are corporate-owned devices, with a policy like that. Remote attestation is fine if it's controlled by the device's owner, and you can certainly run free software on such a device, if that particular build of the software has been "blessed" by the corporation. However, the user doesn't get the freedoms which are supposed to come with free software; in particular, they can't build and run a modified version without first obtaining someone else's approval. At the very least it suggests a certain lack of respect for your employees to lock down the tools they are required to use for their job to this extent.

rstuart4133 5y ago

> I think 3. is very harmful for actual, real-world use of Free Software. I hold the reverse view. The only security token I'd trust is the only thing that isn't open is the private keys the device generates when you press the reset button. The rest meaning from the CPU up (say RISC-V) and the firmware must be open to inspection by anybody. In fact, it should also be easy to peel away the silicon protection so you can see everything bar the cells storing the private keys. The other non-negotiable is the thing that computes and transmits the "measures" of the system being attested to (including it’s own firmware) can not be changed - meaning no stinking "security" patches are allowed at that level. If it's found broken, throw it away as the attestation is useless. The attestation then becomes the device you hold is faithful rendering / compiling of open source design document X by open source compiler Y. And I can prove that myself, by doing building X using Y and verifying the end result looks like the device I hold. This process is also known as reproducible builds. What we have now (eg, YubiKeys) is not that. Therefore I have to trust Yubi Corp. To see what that's a problem, see the title of this story. It has the words "Zero-Trust" in it. In reality of course there is no such thing as "Zero-Trust". I will never be able to verify everything myself, ergo I have to trust something. The point is there is a world of difference between trusting an opaque black box like Yubi Corp, and trusting an open source reproducible build, where a cast of random thousands can crawl over it and say, "it seems OK to me". In reality it's not the ones that say "it seems OK" you are trusting. You are trusting the mass media (places like this in other words), to pick up and amplify the one voice among millions that says "I've found a bug - and because it's open I can prove it" so everyone hears it. So to me it looks to be the reverse of what you say. Remote attestation won't kill software freedom. Remote attestation, done in a way that we can trust, must be built using open source. Anything less simply won’t work.