Nonnegative always includes zero, unless the author had muddled thinking themselves. Since positive is >0 and negative is <0, their negations are nonpositive for <=0 and nonnegative for >=0.
I see your point too, and we're looking forward to a world in which low-power (to enable NFC) open source chips with security features exist. For instance, https://tropicsquare.com is a project that is working towards that.
For now, what we mean by open source hardware is on the one hand that all components are freely available (without NDAs, which nearly all secure elements entail), and on the other that the schematic of the device is open source and passes OSHWA Certification (the CERN license https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-ve... is relevant here). This means that you can in principle build a device yourself. The certification will be done post-campaign (we want to avoid copycat products appearing before ours is available in the open market). Like we did with our three previous keys (e.g., https://certification.oshwa.org/us000155.html and https://github.com/solokeys/solo-hw).
Website can distinguish via the optional attestation key.
In terms of features, CTAP v2.1 (https://fidoalliance.org/specs/fido2/) is still draft only, but yes both v1 and v2 keys support hmac-secret and credential management. We could add authnSelection and authnConfig, but not clear if any browsers actually implement/use it.
The actual public key used for logging in to a specific site is completely random.
Optionally, the website can ask for "attestation", which is intended to prove that the public key is from a specific vendor/model. To make this also unlinkable, devices are supposed to share attestation keys in batches of 100k units.
We hope and think that PIV can replace all the practical use cases for PGP. Specifically among those mentioned, `age` for file encryption, and either FIDO resident keys with hmac-secret for password managers, or something like `passage` (fork of `pass` using, again, `age` for encryption). For SSH you can use FIDO for newer OpenSSH, and either `pivy` or `yubikey-agent` via PIV. Cheers!
As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc.
I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qualified for.
This is what I meant by "safe defaults". Yes some people use e.g. password managers, but no, most people don't. Yes, some people manage to use GPG to manage their ssh keys, but no most people, even qualified, don't/can't/won't.
"Bad defaults with patches hopefully making it safe" is just not the way we should be heading.
In FIDO-speak, "platform" authenticators are your laptop or phone, using their contained secure storage, vs "roaming" authnrs like our SoloKeys. Most people assume that the former will be the main way to use WebAuthn. Consumers using keys are mostly enthusiasts/early adopters/special needs.
Mainly in a corporate setting, a separate hardware key may provide a root of trust (and audit trail if the key is modified to be trackable) , with which you can then unlock your devices in a self-service manner.
You're right that software authnrs are a bad idea.
For services that don't want the security to be pierced by such unsafe fallbacks, initial key attestation can whitelist the acceptable authenticators.
One thing that is too infrequently highlighted is that FIDO2 is decentral authentication between you and the services, unlike "login with big-corp".
The point is that ssh keys lying around on your laptop aren't the greatest idea either. Where is the root of trust? The password you type to terminal if you encrypt them?
FIDO2 starts with the idea of safe defaults, where either client devices (Android, laptop TPM,...) store the keys safely, or dongle vendors (like us, SoloKeys). These have a business interest in doing their job properly.
But there's nothing preventing software implementations, it's an open standard in that respect (I do have other issues with it but your specific concern is unfounded imho).
SoloKeys person here ;) You can implement software authenticators (listening on local USB port), I imagine some password manager people will do so eventually, or have a direct way to hook into requests. Krypton did this for U2F.
Hardware keys are for if you want hardware security, obviously they can't be free unless you want someone with a different business model to subsidise them.
There's an ascending signature counter that's intended to prevent cloned devices (replay attacks are prevented seperately with server generated challenge). One way around it is clone (backup key) having very high initial signature counter set, so first use invalidates original (on loss). But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".
As I'm currently working on possible options to expose on-device keys and cryptography for our open source FIDO2 key (SoloKeys) beyond the FIDO use case, I'd be curious about opinions on just exposing and using the PKCS#11 API (Cryptoki) [0] directly.
Envisioned setup would entail: download (custom) `libsolo-pk11.so`, generate RSA or ECDSA key on the USB key, get public key via `ssh-keygen -D libsolo-pk11.so`, use via `ssh -I libsolo-pk11.so [email protected]`.
The equivalent thing can be done for TPMs with simple-tpm-pk11 [1] today.
Technically, I'd extend the FIDO2 CTAPHID transport with "vendor commands" [2] mapping the basic Cryptoki API, and call that from the custom PKCS#11 shared library, which is then just a simple shim/wrapper. No additional drivers needed (everyone has HID).
Issues I can foresee: Users too attached to GPG workflow. Installation of custom shared library. No SSH support (via PKCS#11) for Ed25519 yet. SSH support for ECDSA only in about-to-be-released OpenSSH 8.0. Vanilla PuTTY on Windows has no PKCS#11 support. Bad rap of PKCS#11 due to existing vendors adding proprietary and closed source extensions. And the fact that SSH (currently) presents all keys to the host - I'd really like to be able to specify which key to use.
Personally, I'm a bit allergic to the GPG/PCSC/PIV/CCID way of doing things... My itch-to-scratch is just having a few keys off my computers (in particular, portable), and perform (infrequent) signatures on the separate device. And do this via a (comparatively) sane, open standard.
https://login.swissid.ch does this too: disallow password managers from filling out the login. Upon asking them to fix: "Autofill completion is not allowed by us for security reasons. First, if that's the case, if someone gets to your PC, we can stop a hacking attempt and that's one of many reasons. For other questions, we are at your disposal."
They also only enforce SMS as two-factor authentication.
The idea of this SwissID is to become a nation-wide identity service, yet they manage to do everything wrong. Yeah, this annoys me to no end :(
Specifically, https://google.aip.dev/assets/misc/ebnf-filtering.txt which is a modification of their common expression language https://github.com/google/cel-spec