Yes, you should be able to. In essence, the state of the TPM is represented in the values of the PCRs (Platform Configuration Registers). Those are hash-extended through the boot process.
You can create a key or similar attribute which has an unlock policy based on those PCR values. If you play back the log of PCR write events from first principles (the log can be captured for debug purposes), you'll put the TPM into the same state and should be able to use anything protected by the respective policy.
For attestation, I presume you're thinking about sending an attested PCR quote - in that case, the TPM uses a non-extractable key to sign the current PCR states. As you can put the PCRs into the "correct" state, you'd be able to get a signed attestation the system is in that state.
The issue so far seems to be that most OSs don't really have an effective way to restrict that file to a single application. User-oriented filesystem permissions don't work, as all software runs "as" the user.
If you assume there's a way to restrict permissions by application (a bit like TCC on Mac for certain folders), you need to then go down a rabbit-hole of what matcher you use to decide what is a "single application" - Mac OS can use developer Team ID (i.e. app signature identity), or similar. You wouldn't want to rely on path or binary name, as those could be spoofed or modified by a rogue app.
So in short, in a multi-user OS, generally the filesystem (asides from Mac OS, under certain circumstances) is fairly widely readable by other software running as the current user. At least in my experience, Mac OS is the desktop OS that is closest to having some level of effective protections against apps accessing "everything" owned by the user (but belonging to other apps).
When you introduce the functionality to disable a traditional safety product, you have to think about the dependency chain and how you design that system to prevent issues. Vehicles with a switchable airbag tend to display a fairly prominent red light when the airbag disable switch is used. I'm pretty sure that on some vehicles I've had, it's hard-wired to light up when the switch is used to disable the airbag. You'd have to break the light to "override" that warning.
It is possible the makers of this product have done likewise, and the arming of their system is done with the same signal that's used to display a green light. But given the sheer complexity of it (Bluetooth, app Integration, server side checks), it seems likely this won't be the case - maybe the light is only momentary, in which case such hardware failsafes won't be in place.
Nonetheless, adding complexity to a safety critical product should be scrutinized and held to the level of engineering as any other safety critical product.
A safety critical product which will cease to function in its safety role without the ability to call home to a server seems to fail at some early hurdles of being engineered as a safety product, so I would respectfully disagree with your starting point that they've thought about this and engineered their lockout as a safety system (since it fails unsafe, rather than safe).
Don't forget their secure boot measures on the onboard microcontroller, to stop malware or a rogue Bluetooth device doing an OTA DFU update to swap around the GPIO pins to indicate "activated" and not actually arm the system...
Some kinds of devices just shouldn't be connected - they should be sold and bought as-is, and function independently of outside factors, as they are safety devices.
Sounds like that's a nice route to forcibly obsolete this well before the end of its usable life by turning off the API servers and saying "it's for your own safety... We have a better newer device now available for only $800 (plus subscription)".
Also a nice single point of failure if you can hijack their DNS and deny every activation request (!)
> The vest won't tell you it's functional and then stop working while you ride. The functionality and payment check happens before you ride, if you read their product description. https://www.klim.com/Ai-1-Airbag-Vest-3046-000
Given it connects to an external server on the internet (even indirectly), it presumably has updatable firmware.
Are you confident enough this company understands secure boot chains well enough to prevent a rogue firmware being flashed? And that they have protected their Bluetooth stack (?) well enough to prevent a firmware being flashed that way?
It's likely (but impossible to tell without doing a teardown) that you could indicate the device is functional via firmware, while not being armed and ready to deploy, if the LED or indicator is on a separate GPIO.
If this was to happen in the supply chain (like used to happen with grey market mobile phone imports getting loaded with adware), that could become a real problem...
Has there been any suggestion as to what happens when the company behind this inevitably goes bankrupt (all companies will eventually fail) or is "acquired" and scuttled? Or they cease to desire to provide the API backend for the mobile app?
It strikes me safety critical equipment is the one time when we don't want any kind of dependency on an external hosted service.
As it stands right now, it seems like even a fully paid-up, owned outright version could cease to function if they lost control of their domain name?
Am I correct in my understanding this product is tied to your phone to "call home" and validate its state? If so, doesn't that mean it's unusable without your phone being working, charged, non-stolen and non-broken? And the same for their servers. So you could in theory go on a journey protected, stop for a break, and find you can't continue your journey protected as you're out of signal, or something has broken?
This feels like a good opportunity for a government to take a stance on safety products. At the very least they'll reduce the amount of eWaste when these stop working before the end of their useful life.
It seems the issue with Ubiquiti here has potential wider implied for users of the equipment (signing keys compromised, cloud dependency giving remote management plane access).
An individual vulnerability in a device is an issue but it gets patched. Hopefully it can't be exploited remotely. My biggest annoyance is when "infrastructure" ends up with outside connections in place (to the cloud or elsewhere), that breaks this model down (trusting the provider to mediate remote access, for example).
They're a big single point of failure, and this incident really proves that.
I guess the concern here is if your VPN was provided by Ubiquiti then you might have an issue.
My approach has been an isolated (read basically no internet) LAN, bridged by a small PC running hardened and locked down Linux. There's no egress from the LAN. VPN access to this LAN goes via the PC under my control, which itself has access to the wider internet via its second interface.
This approach is nice as I don't have to trust any router vendor or proprietary software vendor to be competent, by relying on their equipment to control internet access for devices. Although I recognise this is probably inconvenient for users, none of this is really too impractical - a bit of adverse publicity for cloud and "internet connected", and I could see properly firewalled, egress blocked networks taking off...
(I am more concerned about egress than ingress, because it's the biggest gap most people forget about, and most people just rely on NAT to stop ingress, forgetting any device can phone home anywhere, and they're not monitoring... I don't even allow DNS on that network. IoT that can't handle this just doesn't get in the door)
Under GDPR, a failure to know about (detect) a breach (and then report it yourself) is in itself a violation. Likewise, failing to have suitable organisational and technical measures in place to protect the data is a breach.
I'd certainly argue your inability to account for processing operations after having been breached through lacking knowledge of what was done due to a lack of logs was therefore a breach.
Google certainly seems to do this when it comes to chat applications. Ironically though, they've actually (arguably) lost marketshare - they went from gtalk being pretty widely used (in the late 2000s, early 2010s, as Android took off), to having a confused and fragmented ecosystem (Allo, Duo, Hangouts, Chat, Messaging), and it seems none of those have the same market penetration as the original did.
Perhaps internal competition to that extent simply confuses customers?
You can create a key or similar attribute which has an unlock policy based on those PCR values. If you play back the log of PCR write events from first principles (the log can be captured for debug purposes), you'll put the TPM into the same state and should be able to use anything protected by the respective policy.
For attestation, I presume you're thinking about sending an attested PCR quote - in that case, the TPM uses a non-extractable key to sign the current PCR states. As you can put the PCRs into the "correct" state, you'd be able to get a signed attestation the system is in that state.