g_p

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.

Even with a ported number, inbound call routing still heavily relies on the "number range" owner to direct the incoming call to the correct network.

If the original number range owner has their subscriber database go down, they can't do the lookup for the network to direct the incoming call towards, so it can cause disruption. The same is true if the incoming signalling endpoints are unavailable, as the incoming call requests won't be responded to.

When roaming, your home network is needed for routing incoming calls to you, and handling authenticating your device to the visited network.

There are absolutely ways to intercept a call from a targeted user that would be viable to use to gain access to a mid to high value user's funds.

SS7 call routing and rogue 2G base stations are some potential approaches.

In terms of banking security, a good (ideal) architecture would treat the user PIN as a credential which is not transmitted over insecure means. Unfortunately many banks don't do this right, and still support bank-side PIN verification (with the PIN sent over the wire to the bank), rather than using the bank card's smart card features to carry out on-chip PIN verification.

If you built a bank from scratch, for security first, you'd likely still use smart cards as bank cards, but you'd only do PIN verification on-card, so the user PIN is never exposed to even the bank - the card can securely vouch for the PIN in a manner that's far more costly for an attacker to defeat than using a $5 wrench against the user of the card to make them reveal the PIN (h/t to XKCD).

Sending the card number and PIN over the phone is just asking for trouble - mobile phone calls are decrypted at the base station and available in the clear, before being transmitted up into the wider telecoms network.

You need a SIM card (ideally) with support for elliptic curve crypto, and some additional fields added in the profile (SIM services 124 and 125). You can then, once those services are enabled, place network public keys on the SIM itself.

There are 2 ways to do SUCI calculation - both require SIM support to hold public keys. SUCI-on-SIM requires a SIM that can do the encryption to the public key on the SIM itself, and issue that in response to the IDENTITY command; SUCI-on-phone requires a SIM that "just" has the public key fields present, and the handset can do the SUCI calculation and encrypt the SUPI for the public key stored on the SIM.

Either way, your scenario isn't using SUCI concealment by my understanding, unless you got a new SIM card, or it was reprogrammed somehow to support the SIM service fields needed (but I'm not aware of operators doing that).

In terms of existing examples, there's a few equivalent (or at least similar) fields defined as SIM files - for example, the FPLMN (forbidden PLMN) list of networks your phone shouldn't attempt to attach to.

You're right that this needs limited at the modem - but the main user accessible method of configuring the modem is the phone UI. As this setting is one which needs network support, and is likely to disconnect a user who misconfigured this, a SIM file for permitted RAT (radio access technology) types would make sense, as SIM files are under the responsibility of the operator.

Where this would get complex is edge cases, like under roaming scenarios, where your home network can't predict what might be available, and your handset may need to permit downgrading to a technology not permitted on the home network.

The toggle in Android to disable 2G seems a start towards a user accessible setting for this, which selects what the modem is willing to join, but it's certainly far from a user friendly way to enable and disable particular technologies.

5G Standalone security and privacy requirements

To help ensure compatibility of iPhone and cellular iPad devices on private 5G SA networks, infrastructure vendors must adhere to the following security and privacy requirements:

Privacy concealment: The Subscription Concealed Identifier (SUCI) must use a non-null protection scheme. This can be achieved through either an on-SIM SUCI calculation or an ME SUCI calculation, as outlined in TCA 2.3.1 and 3.1 specifications. For detailed information, refer to the 3GPP Technical Specification 33.501.

(From https://support.apple.com/en-gb/guide/deployment/depac674731...)

This pertains to private networks rather than public operator networks, but it certainly seems to imply that use of SUCI is an expectation on 5G SA networks (private in this context).

A lot of the patents needed to implement mobile standards are designated as "standards essential patents", meaning that the party bringing them up the table in the standards committees needs to disclose them and agree to licence them on a FRAND basis to anyone who asks (fair, reasonable and non-discriminatory).

In many cases there are patent pools you can license that cover large areas of the standards, without needing to negotiate each one individually.

Many very fundamental parts of 4G/ 5G are patented and you'll not be able to get your device to work on the network without those patents, so Apple will have licensed those patents under FRAND for their new C1 modem.

You might find Privacy Pass of interest then - https://help.kagi.com/kagi/privacy/privacy-pass.html

It should be out in the next day or so.

There's a couple of options in settings worth checking, as Netguard works for me when roaming just fine.

Under Settings > Defaults, make sure you don't have "block roaming" turned on.

Expand the rules for the apps giving you issues, and check "Block roaming" isn't ticked for them.

I recently came across a signature check that was (correctly) checking the signature against a public key... The issue was the public key itself was unauthenticated, and provided by the (signed) ciphertext itself... Meaning the crypto was fine, but it wasn't checking anything meaningful, as any rogue message would just include its own public key in the message!

It's not only about the raw operation of checking bytes are equal (hopefully in a constant time manner, if applicable), but also about ensuring the desired security properties are actually present in the application!

Thanks - yeah it seems like this is supported in FIDO 2.1 (but not 2.0). I suspect this is only implemented in Yubikey 5.7 and above.

Once the technology is there to support it, hopefully the user experience part can be improved with time.

Ref in the standard - https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...

That's a pretty neat solution. I like that idea.

If you wanted to go a step further, you could use a smartcard with hardware PIN reader as a PKCS11 crypto device, and use that to decrypt the long lived keys in the store, then pass it back to the host encrypted by a platform-protected key to be decrypted and used.

If you could get the right implementation specifics together, you could likely then have the smart card simultaneously re-encrypt the credential with a key bound to PCR state of the TPM via a policy. You'd then decrypt that ciphertext on TPM without a PIN, but conditional on PCR state of a couple of PCRs that represent your system like the secure boot toggle state and allowed CAs.

That lets you be a bit more "cross device" than a fully TPM solution does, though your certificate technique works fine as long as you keep an offline backup for enrollment if anything changes on your system.

That's a fair point, although as the PIN is validated locally, you could argue from the server perspective you gain a second (knowledge) factor, but from a local perspective it's entirely correlated with the existing stored factor (a weakness in the local device implementation can skip that PIN check and yield the result).

Perhaps this is excessive, but it's a model where I like to see layers of security that depend on different, uncorrelated failures being required to bypass them.

Today if you want to get into an account using "FIDO2 as MFA" you need both the account credentials or ability to reach the Fido prompt (say password reset), and the hardware token device (with optional pin). The device alone being compromised shouldn't get you into the account.

I share your paranoia and felt that passkeys were a step back as anything getting access to your browser extension memory can realistically dump both your "password" and MFA ("passkey") in one move.

I wonder if there would be a way for vaultwarden to wrap passkeys such that a hardware FIDO2 key is needed to decrypt them "per-use", and prevent software on the host from stealing a pile of passkeys that give direct access to accounts without further MFA.

Right now it feels like passkeys in the password manager is akin to storing MFA seeds and recovery keys in the same password manager...

Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution).

This adds another step needing considered for a user, as finite storage means a whole edge case to consider (can't register as slots full), and no simple actionable step to take ("which account would you like to never be able to log into again?" or "sorry you need to wipe this key and lose everything, or buy another one")

I feel there is a usability aspect of FIDO2 (for non-resident MFA) that is being overlooked - the paradigm was simple - a physical key you don't lose, and you can have multiple keys. The gotcha was no way to replicate backup keys, which becomes fairly difficult for users. But hey - passkeys launched with no export or migration process between closed device ecosystems!

From my perspective though, I won't use passkeys until I get sufficient control over them to be allowed to decide if I want to make them "resident" or not. (I don't want resident keys!!)

I want to use non-resident keys everywhere as a hardware-backed second factor that is phishing resistant, without capacity limitations (so zero cognitive burden on whether to use or not).

It feels like a regression for passkeys to be forgetting about what (for me at least) was the core basic use-case of FIDO2 - as a highly secure second factor for someone who already can manage storage of secrets in software, and just wants high assurance phishing resistant MFA during their conventional login process.

The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA.

The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials.

That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts.

I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).

TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe).

Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.

Which? is a UK brand, and in the UK it's fairly common to see the postcode (or rather the first couple of digits) used to determine which regional programming a user wants, given the (to some extent historical) TV regions and channel numbering.

I've seen "always offline" pre internet era satellite TV set top boxes do this, and use the first 2 or 3 characters of the postcode to work out the correct region and show the correct programme guide information and channel numbering.

I imagine that on a modern internet enabled device this might also pre-select some of the "watch later" apps, based on your region.

Doesn't mean there's no wider issue about data gathering and exfiltration over the internet, but just to add some regional context as this postcode point might not be as egregious as it sounds at first.

Readeck saves an archived copy of the links you save (where it can).

From their docs, "Every bookmark is stored in a single, immutable, ZIP file. Parts of this file (HTML content, images, etc.) are directly served by the application or converted to a web page or an e-book when needed."

https://codeberg.org/readeck/readeck

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 browsing a site full of JS-heavy ads, sure.

When running a browser performance benchmark, generally not - the ad block extension adds an overhead to the page. I saw this when experimenting with Orion Browser on Mac, which uses the Webkit engine, but adds support for many Firefox and Chrome web extension APIs.

In experimenting with that, I noticed that enabling extensions and using many extensions during benchmarks could easily impact on scores. Even just an ad blocker like uBO had a measurable impact on a benchmark, from my recollection.

One other potential area of variability could come from browser extensions - I imagine that users who compare browser power performance are more technical than the median user, and are more likely to run browser extensions (e.g. ad blockers, etc).

Given Chrome has a larger and more extensive collection of extensions, perhaps users who see differences are running more browser extensions in their Chrome installation, which impacts on performance/power usage?

Certainly interesting to see these assumptions put to the test though, and get some data around them. While it looks like it may have fallen behind again a little, I noticed Firefox's browsing performance on Speedometer caught up for a while, contrary to what I had thought/assumed.

It certainly does - if you remain current then not a lot has really changed.

If you understand the principles of control systems and how an electrical grid works, this is broadly "just" a grid stability concern.

To some extent this feels like an issue of IoT-ification of things that we otherwise understood just fine! Maybe the real issue is how we blend cyber security knowledge into other sectors, and quantify and ensure it is present?

A good point - perhaps the focus is too heavy on paperwork or "measurable compliance".

From experience in this sector though, I think the real issue is a lack of technical awareness and competency with enough breadth to extend into the "digital" domain - often products like these are developed by people from the "power" domain (who don't necessarily recognise off the top of their head that 512-bit RSA is a #badthing and not enough to use to protect aggregated energy systems that are controllable from a single location).

Clearly formal diplomas/certificates are not needed for that - some practical hands-on knowledge and experience would help a lot there.

When a product gets a network interface on it, or runs programmable firmware, we should hear discussions about A/B boot, signatures, key revocation, crypto agility to enable post quantum cryptography algorithms, etc. Instead, the focus will be on low-cost development of a mobile app, controlled via the lowest-possible-cost vendor server back-end API that gets the product shipped to market quickly.

Let's not even go near the "embedded system" mindset of not patching and staying up to date - embedded systems are a good place to meet Linux 2.4 or 2.6, even today... Vendors ship whatever their CPU chipset vendor gives them as a board support package, generally as a "tossed over the wall" lump of code.

I doubt many of these issues (which seem to be commercial/price driven) will be resolved through paperwork, as you say.

Given the challenges of techniques like TLS interception (i.e. through pinning and other good security features), about the only measure I can see left is network isolation.

You can set up a local network that has no WAN connectivity on it. About anything else is difficult to verify even the most basic of security properties. Certifying is another step up (although you could argue certifying is just a third party saying something passed a finite list of tests) - the real challenge is defining a meaningful certification scheme.

There has been some good work towards consumer IoT device security (i.e. the 13 steps approach from the UK), that covers some of the lowest hanging fruit - https://www.gov.uk/government/publications/code-of-practice-...

The trouble is that these set out principles, but it's hard to validate those principles without having about the same amount of knowledge as required to build an equivalent system in the first place.

If you at least know the system is not connected to a WAN, you can limit the assurance required (look for WiFi funcitonality, new SSIDs, and attempts to connect to open networks), but at a certain point you need to be able to trust the vendor (else they could put a hard-coded "time bomb" into the code for the solutions they develop).

I don't see much value in the academic/theoretical approaches to verification (for a consumer or stakeholder concerned by issues like these), as they tend to operate on an unrealistic set of assumptions (i.e. source code or similar levels of unrealistic access) - the reality is it could take a few days for a good embedded device hacker to even get binary firmware extracted from a device, and source code is likely a dream for products built to the lowest price overseas and imported.

They don't need to break into separate sites though - the issue at hand is that a single failure in the centralised "control plane" from the vendor (i.e. the API server that talks to consumers' apps) can be incredibly vulnerable.

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.

https://rya.nc/vpp-hack.html

The Microsoft view is that LTSC is for "single purpose devices", more akin to appliances or embedded systems (https://learn.microsoft.com/en-us/windows/whats-new/ltsc/ove...)

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.

There absolutely are access control systems out there using PKI. For example, the PIV specification (a la DOD CAC) slot 9e is intended for "card authentication" without a PIN typically being required.

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.

Presumably you sign the emails rather than encrypt them?

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.