3,612 karma · joined April 11, 2016
Here's a recent example where a 512-bit RSA signing key was being used to sign JWTs, allowing a "master" JWT to be signed and minted, giving control of every system on that vendor's control system.
Those tend to be shipped on some validated hardware that will take years to validate, then eventually gets approved for use, and won't be replaced for many years. My guess is in many of these use cases (industrial etc) you won't see TPMs present or used, because they value availability and uptime over all else (i.e. confidentiality and integrity) - you won't be encrypting the filesystem or doing any kind of TPM checks on an industrial control system, as the operational technology mindset is to put availability above all else, and a TPM or encryption issue would compromise availability.
So not really for workstations - they'd probably say you should use enterprise and just accept constant changes and new features being pushed down to users causing support hassle. They don't officially consider LTSC to be something used by regular users for daily productivity though.
PKCS based cards get all the benefits of smart cards (hard in theory to extract keys, side channel resistance, etc), with the usual risks (trust in vendors and issuers to not add backdoor APDUs to applets etc.)
Doubt anyone would want to use FIDO2 for a door access control system, but in theory there's nothing really to stop you, if you come up with a clever URI schema for your doors and know what public key to expect for each identity on each URI. That's where FIDO2 wouldn't be ideal, as you'd get a different identity on each URI, so it would only really work with a single URI (zone?) for the whole site, and implementing zone access checks at each individual verifier.
Realistically, doing a PIV style PKI verification would give you all the benefits of FIDO2, but also with the ability to handle card revocation etc via a CRL that's distributed through the system.
Otherwise anyone who knew the public key of the server (which shouldn't be presumed secret) could send an encrypted instruction, and it would be acted upon, and past encrypted instructions could be replayed.
Something else that would be a challenge for your idea would be how to handle the orders of magnitude efficiencies in scaling gained from digital technology.
Emergency call centres often (or at least should!!) have these paper or card based backup processes - notes are taken on the card based on the call, addresses written manually, and the card is carried to a dispatch desk (perhaps sitting on a handheld radio if the main system is unavailable), passing information to response teams. Handling of each call requires more people, and gets you a much lower throughput (manually writing addresses, without lookups for spelling correction, reading them with phonetics over the radio to drivers etc).
How many times have you tried to call a business during an incident or disruption and been unable to get through on the phone, because they aren't staffed to a level that can handle any significant % of their customers calling at once? (Often, these companies lack tech company style realtime status pages as well, which could arguably reduce call numbers).
I do think there's some merit in trying to help organisations improve process and procedure resilience, but it doesn't strike me that it will be effective unless normal staffing levels are nearer the levels needed for "crunch" operations (or people are kept "on call" at extra cost to be available).
There are however a lot of good lessons that should be learned from the wider fiasco around technology resilience and systems design, and part of that should include independent (with as close to entirely independent failure modes as possible) redundancy systems.
You could get a Solarwinds type situation where the adversary has the signing keys and ability to publish to the website.
You might also find that the vendor ships a library (like libxz) as a part of their invisible or hidden supply chain, that is able to be compromised.
You might find that one of the people working at the company makes a change to the code to enable remote access by the adversary in a targeted collaboration/attack.
The problem isn't that signing key (although I could delve into the lengths you'd need to go to to keep that secret under these threat models) - the problem is what they sign. A signed end release binary or series of packages isn't going to address the software source code itself having something added, or the dependencies of it being compromised.
Therefore they do not seem particularly bothered by this rejection, as it was not going to let them get the "full" version working anyway.
That is likely even lower than the effective self discharge rate of a lithium coin cell battery. I don't believe the Arm equivalents like the Cortex M0 can deliver such low absolute current - maybe microamps, but more than an MSP430 from what I can see.
Ref - https://metebalci.com/blog/measuring-the-power-consumption-o...
Perhaps they'll relax the restrictions on "non first party" components (likely you'll lose some functionality that aftermarket parts don't actually support), but use pairing to lock out parts from stolen phones.
I suspect that part of their strategy is to try to make stolen iPhones less attractive to thieves, and effective parts pairing would likely reduce the market for stolen phones stripped for parts.
Of course, if you can "blank" off a stolen part to appear as an unofficial one, that doesn't work! That idea is therefore likely to face challenges.
The challenge will be what is really meant by parts pairing - to some extent if you want to do some features securely (say touch ID), you probably want to pair the reader to the secure enclave with a shared AES key and similar. There could be tooling to reset and re-establish that pairing on an unlocked device.
Legislation often struggles to define exactly what is required though, so it will certainly be interesting to see how Apple responds.
Hence you'll often notice UEFI updaters turning off bitlocker.
I've seen HP devices tell you what the value of PCR0 will be for each given update, meaning you can know beforehand what that will be, and prepare by locking measured boot to that value before rebooting.
In Linux with systemd-measure, there's an option to lock to a signed manifest for PCR11, so you can have updated kernels (UKIs, for example), able to boot, while still locking the measured boot to the kernel image, initrd, cmdline, and public key used to sign the values. At that point, your OS distribution (or yourself) can take control of that process. It doesn't help for firmware updates though, as far as I know, unless you can prepare and ship an updated PCR policy, and your OS distribution is unlikely to be tightly integrated with your hardware vendor to do that, so it will likely fall onto the user, or to unlock the disk while doing those updates.
By my understanding , in principle yes you could use ZK proofs - you can imagine it as a way to prove a certain assertion (age >= 18) in a way that isn't directly linked to other data. You sometimes see this in conceptual ID card specifications - using keys on a smart card to give a signed attestation about a single attribute without sharing other ones.
Ultimately though, when you need to actually implement it, you'll end up needing the same core concept as the thought experiment above - you'll need one or more "trusted central authorities" whose word is trusted on a given asserted attribute (age, etc).
They'll need a way to prove that they vouched for a user (as there's no digital way to validate their age as that's an unverifiable claim). You'll then need a way for the "bearer" of a ZK proof to tie themselves to that trusted central authority's attestation, and you'll need a way to prevent the information needed to generate that ZK proof being shared with others for replay.
A ZK proof will still need that external trusted authority for an attribute like age, because age isn't something you can root some kind of cryptographic trust from.
I'm not an expert in the ZK crypto either, but it doesn't deliver a magical ability to prove a (biological analog world claim) without chaining back to a trusted verifier of said claim, and effectively delivering that sort of "thought experiment" protocol.
Sometimes though, the complex solutions tend towards the simple - you could issue people "age verification" smart cards (if you have enough confidence in CC EAL6 or similar cards, and their side channel resistance) which are "group keyed" with common attestation signing keys for every million (or another suitable anonymity threshold) users, and share the public keys used (to allow verification you haven't been given a special unique public key), and then allow signed card-issued anonymous attestations. That would work for as long as you can keep the smartcard-backed key secure against side channel/ key extraction attacks.
The user adoption challenge in all this is getting users onboard and demonstrating it's a private solution rather than an excuse to oversee their online activities more, but I do believe you could do this in a manner that's going to make it easier to just identify them from IP address and adtech trackers or similar external means.
As an overly simple thought experiment, you could generate a random ed25519 ephemeral public key, hash it, then send it (blinded, and thus unreadable) to an age verification service (with some long term age verification credential or similar).
The age verification provider does a blind signature on your (blinded) public key hash, and sends it back to you. You un-blind that signature (meaning that provider can't identify which identifiable request led to it, but now it bears the hash of your public key), and you can now authenticate to a service by signing a challenge with your ephemeral ed25519 private key.
The service only knows your ephemeral public key, and that it has been "vouched" (signed) by the age verification provider.
The age verification provider knows "you" asked for a token , but doesn't know what public key you used.
Clearly there are challenges with replaying (authorised user could share the private key every day with a group of others), and revocation of a credential whose private key gets shared among a group is hard (beyond providers blocking a public key).
The risk is that this becomes a race towards "DRM" and platform attestation/authentication to try and prevent private keys being exported.
To turn the question around a bit - you've identified the possible routes of compromise/exploitation (i.e. untrusted user input). The first step to me is a threat model. Work out the "so what" of why someone would try to attack you. What would be their end-goal?
To give you a few first steps, you've mentioned using a Google Maps API, and searching based on device location. Presumably your use of the Maps API is paid, and therefore a potential motivation for an attacker is financial, coming from your use of that API. Therefore treat that (i.e. the ability to make requests using your Google Maps API key) as a "target" in your architecture.
From there, you can do things to be a less attractive target (rate limiting, limiting results shown, if you are charged per-result). You could also review your code logic to ensure that only the right kind of request can be made (i.e. that someone modifying the client-side can't trick your server into accidentally making entirely arbitrary paid maps API requests on their behalf).
At this point, you'd also want to figure out your threat model between client-side and server-side, and what is exposed where. Assuming your server-side makes the API requests to Google Maps (and if not, then you're presumably exposing your API creds to clients, which is a "stop right here, don't proceed" moment!), what is allowed to flow from client to server? Can a rogue client get your server to make an arbitrary query? Would that let them use you as a free Google Maps API broker?
Understanding the trust architecture between front and back-end is (for me at least) key, as that's the primary exposed attack surface to an end user. Open up developer tools (F12), and look around requests as you use the app. Is there anything here that you wouldn't want users to see? As attackers will definitely see that, and it will be the first place they go to look at what you are doing!
Other ways to mitigate these risks could be (if you have sufficiently constrained input sets) to implement caching to avoid the ability to rack up queries against the underlying maps API. Given you are using arbitrary user locations, that's a bit harder. If users have a session or other short to medium term identifier, you could do some smart rate limiting to detect rampant scanning of large areas by making API requests that spoof the device location to be loads of different locations.
If you follow this process, and work out what's worth attacking (your infrastructure will be one of them - even just to compromise the site, post spam, etc, as will things like any database you run), then you can begin to understand those risks, and work out where there are attack vectors, and mitigate them methodically. The OWASP top 10 guidelines are a good starting point - often the biggest issues are design mistakes, omissions of basic omissions, or flawed attempts to implement basic measures. If you have authenticated API endpoints, for example, is the authentication logic correct, and meaningful? Does it actually do what you intend, and is what you intend sufficient for the level of security you want to have?
Hopefully the VM/container run environment is also in a network-isolated environment too, so it can only be accessed and invoked through the expected routes, and it can't make arbitrary network calls to external hosts that haven't been manually reviewed and approved.
Since Apple won't implement any third party one, and theirs is natively integrated with their platform, half the ecosystem won't implement or adopt any FOSS alternative.
Since such an alternative won't be pre loaded on handsets (and the Android ecosystem is complex without one single vendor producing firmware everyone ships), the rival would need to be installed manually by users before use.
Not impossible - WhatsApp and other apps have (in some markets) gained near-ubiquity without being built-in, but I think the native app barrier here will always be a hurdle. And Apple presumably knows and strategizes that an alternative won't gain adoption if their half of the ecosystem won't adopt it, therefore holding back the wider market and keeping airdrop functionality as a USP.
Another part of the challenge is the commercial business models part - monolithic RAN vendors can integrate vertically and horizontally to offer a fully tested suite that goes beyond just what's in the standards. To get like-for-like performance in things that matter, you often need more than the base standards. For example there's all manner of proprietary data exchanged between radios to coordinate performance and interference, which is vendor proprietary. That's needed to win an edge over others and win contracts, in the eyes of big vendors.
The issue right now is that even just getting 2 standardised boxes to work together needs exactly that testing you refer to - different versions of ASN.1 schemas for example, can break interop. There's often vendor tweaks to edge cases to fix interop.
In the old world of a single vendor networks there was some "goods out" testing carried out on equipment to ensure it worked together as a solution. When you buy components and put them together, you need to do that testing (hence labs like this).
One final interesting challenge will be around funding future R&D. Big telecoms vendors need to invest many billions per "G" to keep up and get patents into standards. Open RAN is likely to drive disaggregation and cost savings for operators, which will reduce margin and "fat" in contracts. That might make it harder for innovation in the "next big thing", if they can't make a profit from charging a margin on some COTS servers or software platform. Which isn't to say that more competition is a bad thing, but just that disaggregation might cause a slow-down in future innovation if reduced margins can't sustain it. Operators want Open RAN for cost savings, and that means someone's margin needs squeezed.
And yes, it's only $10 or thereabouts for a logic analyzer that can decode LPC bus communications.
2019 ref - https://pulsesecurity.co.nz/articles/TPM-sniffing
Isn't this really a process problem (i.e. a missed requirement), so that after the first instance of a queried match (for whatever reason), the unrelated death record (which will have some kind of unique document identifier or can have one derived from the information on it and date of issue) can be excluded from being matched against the subject user? (As realistically you could have 2 people with same name and DOB, it seems like the issue here is not data quality.)
It sounds like nobody created a requirement in the design stage for the ability to say "I've checked this, it's not the same person, don't flag this same death entry again". That's maybe not something envisaged at requirements time, but the need for it now becomes apparent.
2x fairly prominent Fujitsu people have been interviewed under caution on suspicion of perjury, and some of the recent revelations from recent testimony in both the parliamentary committee hearing and the public inquiry seem likely to open the door to further such investigations.
In terms of internal conduct, the Post Office is now (as of first week of January) apparently under investigation for potential fraud offences. There is some speculation this includes individuals, as well as the entity itself (given many fraudulent actions would be carried out by individual people).
I imagine such prosecutions (properly carried out, independent of government actions) may help focus people's memories and also begin to start the process of punishing those individuals concerned, and implicate others in the process.
One of these is "ads/trackers". I imagine that it would be feasible for this to include some of the more common affiliate URL types, or third party lead/affiliate tracking bounce hops like awin.
Clearly there will always be some amount of ability to "defeat" this kind of measure by obfuscating links, but eventually the user needs forwarded to a link that has a referral parameter or a site that sets an affiliate cookie or similar.
The "tracker category" also can give a bit of extra information - things like "invasive fingerprinting, advertising"
Given many of the sub post masters struggled to fund their legal cases (and legal aid is not likely going to stretch to funding the intensity of expert witness work required to discredit a whole system), this also seems to be one of the non technical failings not often talked about.
There's certainly questions about why courts didn't spot issues, but ultimately the common law adversarial system assumes both parties can get equal quality of representation. Unless you have very strong technical knowledge (this site is a non representative sample!) you'd struggle to really shed any light on the bug and get a court to agree with your line of defence.
Ultimately that's what did happen in the group litigation by Bates, about which the TV drama was ultimately created.
It's worth checking exactly what is encrypted as I don't think folder and file structure and names were encrypted.
A lot of what seems apparent in this case is that contractual and commercial factors weren't set up correctly - they were set up to deliver predictable prices (loved by public sector clients), but not necessarily to deliver good outcomes.
An example - it appeared much of the rush to ship the point of sale terminals was to get through customer acceptance (and presumably the payment milestone), despite scope creep and quality issues. And there was a cost for PO to access audit logs, and limits on capacity of these logs which could be handled. Presumably this delivered a lower headline price for an accountant negotiating the price down, but it ultimately made a poorer solution that wasn't for for purpose.
It seems like (from what I've seen of the evidence) nobody internally in PO really had full understanding and ownership of the project and they'd outsourced that (but kept the suppliers tightly commercially managed, creating the incentives for shipping poor quality code, rather than spending the time to polish it, as some had tried to do in the development team).
Some interesting evidence here in the inquiry on software development practices and low competency and quality of code - https://postofficeinquiry.dracos.co.uk/phase-2/2022-11-16/#d...
One potential mitigation might be to require them to expose all "prompt" data and similar context as plain source users can see (which would effectively kill off commercialization, but allow users to see what the model was promoted to do).
We'll soon see attacks like SSRF/CSRF and similar play out in terms of asking a model to make a POST request containing user data, or rendering arbitrary JS (or putting arbitrary code into code a user is asking to have written).
I don't know if forcing the full prompt and context to be visible and open for scrutiny would help entirely, but it feels like it ought to start things off by at least helping users look for absolutely blatant issues in the prompting.
Which flow and service/grant etc seems to matter a lot, and be a good example where you'd want a very clear playbook of step by step instructions that you can hand off to someone else to unambiguously follow.
This was why infotainment systems lagged the state of the art for so long - they were apparently shipping components that would have belonged in a smartphone from more than half a decade before.
In this case, I believe we had a few phones get A/B updates by Android 7, which was late 2016. Giving it a year or so to filter to more CPU chipsets, that would mean (if the old rule held true), we would expect to see A/B hitting new cars in the next year or two. This assumes auto makers are using enough of the Android BSP to get the bootloader with A/B (which isn't a given), and then that they use it!
Anyone with any experience of auto software know if the teams doing software are experienced and understand the platform side of things, or if it's a traditional front-end heavy "crunch release" type affair? I've seen some pretty poor quality infotainment systems in the past, so my assumption is inexperienced devs with limited platforms knowledge, focused on "get it working to ship it", but would be interesting to hear from anyone with experience of how this really goes down.
Not that there's likely to be any real repercussions in many places given a lack of criminal enforcement around theft/fraud, but EV charging requires the user of the stolen card to stick around in a given area to charge the car, so it's likely lower risk than other places where a stolen card can be used for a large transaction in a short period of time.
I imagine you'd eventually get some people going around offering people "cheap" EV charges for free (for cash), and then tapping a stolen card on the reader, but there's always going to be someone trying to exploit stolen cards in innovative ways.