I wonder why do they need the whole secure channel thing instead of making the card hold a client certificate and use standard mutual TLS with their backend server.
As adev_ mentioned, TLS implicitly requires a lot of things that can be considered expensive for very low power devices (dare I say "bloat"). Examples being things like X509 certificates.
Another thing to consider is that TLS supports multiple use cases and has multiple versions, so it has stuff like algorithm negotiation, version negotiation and some other things that are really unnecessary when you just want a secure channel between two parties with pre-shared keys[1]. If you strip all those extra things from TLS you'll basically end up making your own protocol anyway.
What I'd like to see is a standardized protocol for this exact use case: two parties with pre-shared public keys, no algo negotiation[2], and only sending what's really needed over the wire without extra metadata. TLS is not quite right for this use case IMO.
[1] Yes, TLS-PSK exists but it's largely an afterthought and not always implemented by libraries, because it's considered a niche use case for TLS. To some degree, same thing can be said about client certificates.
[2] I think the article does say that they have algo negotiation in their custom implementation anyway. Personally I'd hardcode something like ChaCha20Poly1305, mainly because it's reasonably fast in software and on low-power devices.
I agree that runtime algorithm negotiation makes sense to avoid sometimes. So just make a spec that factors out the algorithm, and make the choice of algorithm a compile-time thing.
Then there's no need to hardcode anything in the spec, you can just say you're using the protocol RFC-12345-ChaCha20Poly1305 — with RFC-12345 being the spec that leaves out the algorithm.
Yes, that's pretty much what I meant by "standardized". You'd be able to pick AEAD cipher, KDF, signature algorithm, KEX algorithm etc., while the spec would only describe the protocol itself without enforcing specific algorithms. Noise Protocol pretty much does this already: you provide a string that describes the set of algorithms you will be using, e.g. "Noise_NN_25519_ChaChaPoly_BLAKE2s"
I've heard about Noise but didn't think to mention it for some reason. Yeah, Noise is basically what I was trying to describe. Such a protocol doesn't necessarily have to use Noise though, however Noise helps avoid some implementation pitfalls that people not very experienced with crypto can make.
Smartcards, including the contactless kind (often called NFC, but that’s technically a related but different set of standards), have been able to perform RSA signatures since the 90s.
A secure channel between a backend holding the keys (usually in an HSM) and a card read by a mobile device is pretty standard, actually. That's how remote card top-up usually works.
The relevant smartcard standards (ISO 7816 or GlobalPlatform, I can't remember) provide that type of secure channel protocol by default.
My Yubikey (which I imagine is a bit more sophisticated than a NFC tag can be) is said to be able to hold Ed2519 keys and use them for signing, but I was never able to actually do that. :)
Elliptic curve signatures are even easier since they're computationally less efficient and can be implemented in software on newer smartcards!
I'm using a GPG key on my Yubikey, and while I haven't tried using Ed25519 and Curve25519 in particular (GPG support for these is still not ubiquitous), the GPG smartcard application in general works quite well for both SSH and actual OpenPGP use.
> Your budget in term of compute and memory is extremely low. I would be surprised a proper RSA/ECDSA signature from an X509 certificate can hold there.
The latest versions of the Java Card spec have VMs on them and have HTTP interfaces:
Not at all: NFC (or more accurately ISO 14443) is often used as just another interface for regular ISO 7816 smartcards.
There are other contactless standards (storage only, proprietary fixed-function logic etc.) too, but full-fledged Java Card smartcards are actually quite common: It’s what most contactless payment cards are.
> I'm currently analyzing the possibilities of using Yubikeys for TLS client certificate authentication over NFC on iOS devices as part of a single sign-on process, but from what I have been able to gather only OTP seems to been supported? Are there any plans for supporting PIV over NFC?
> This paper introduces a new online payment protocol called EMV-TLS, dealing with NFC enabled mobiles. EMV-TLS results from the merging of three technologies: EMV payment applications, SSL/TLS secure channels, and Near Field Communication radio interfaces. The main idea of this protocol is to remotely use an EMV-TLS chip, thanks to a secure TLS channel established with a server. The mobile acts as a passive modem that manages TCP/IP resources. Two classes of servers are defined; N1 class may only read the embedded information (card number, bearer name, validity date,), while N2 class has access to all chip resources and may generate cryptograms. A first experimental platform including an EMV-TLS chip, an Android mobile, and a TLS payment server has been realized as an early proof of concept.
> This paper introduces a new mobile service, delivering keys for hotel rooms equipped with RFID locks. It works with Android smartphones offering NFC facilities. Keys are made with dual interface contactless smartcards equipped with SSL/TLS stacks and compatible with legacy locks. Keys cards securely download keys value from dedicated WEB server, thanks to Internet and NFC connectivity offered by the Android system. We plan to deploy an experimental platform with industrial partners within the next months.
This document describes the support of the TLS protocol over the NFC
(Near Field Communication) LLCP (Logical Link Control Protocol)
layer, which is referred as LLCPS. The NFC peer to peer (P2P)
protocol may be used by any application that needs communication
between two devices at very small distances (a few centimeters).
LLCPS enforces a strong security in NFC P2P exchanges, and may be
deployed for many services, in the Internet of Things (IoT)
ecosystem, such as payments, access control or ticketing operations.
Applications secured by LLCPS are identified by the service name
"urn:nfc:sn:tls:service".
To be fair, that's the "connected edition" variant of Java Card 3 – to my knowledge, nobody actually uses that.
But even the "classic edition" usually supports regular secure channel communication. It's not TLS, but it achieves the same outcome (i.e. secure remote card access by a remote conceptual terminal).
That's what is done in Brasil for dealing with their IRS (it's optional for physical persons, but mandatory for corporations) google for e-CPF and e-CNPJ (the brazilian tax IDs for people and corporations, respectively). The brazilian IRS started using digital certificates some 20 years ago, and specially for corporations it greatly improved the life of accountants.
> Why not do the same thing credit cards or access smartcards do?
I think you would be surprised how bad the security on these systems is.
The credit card security relies mainly on the ability of the bank to rollback in case of "a shit happened" and in the payment terminal itself.
Probably not something you want to see to protect against identity thief nation wide. And you also can not trust individuals smartphone to do the right thing.
I think this is not true in most of the cases. The (security) technology behind the debit/credit cards using the SmartCard chip (IC) is pretty ubiquitous. It is the same as the security technology guarding the SIM cards in your phone and even your eSIM. Basically the protocols and the interface specifications are the same. In the end, they are just smart cards. Imagine this technology not being strong enough, because I remember the days when the security of the pre-paid public phone cards was quite rabish and any kid with some skills and knowledge could forge a card with unlimited credit.
It very happens that the father of the smart card technology to be a french guy [1] and the current biggest provider of this technology is the french aero-space/defense/security company Thales Group[2] followed by another frech company called IDEMIA.
There is a very nice biography of the technology [3].
> The credit card security relies mainly on the ability of the bank to rollback in case of "a shit happened" and in the payment terminal itself.
That's certainly not right, the electronic chip in a payment card relies on cryptography, and if you used than together with a PIN the bank has a strong argument to not rollback anything. If you're using a debit card like most of Europe, you're going to have a hard time convincing them.
I believe they are hoping to make a system which adds some sophisticated capabilities - for example:
* Can't read any identity information from the card contactlessly without a PIN, so you need somewhere to enter the PIN.
* Ability to prove your age without disclosing your identity, so you need somewhere to choose how much info to share.
* To validate ID cards for people whose phones are dead, the ability do to the above securely even on a sketchy nightclub bouncer's phone.
* Making all this stuff accessible on normal people's phones, not some $$$$ dedicated reader hardware.
* Ability to provably give another person permission to collect a parcel for you (I can only assume French parcel services are a lot more fastidious than ones in my country) with four-way coordination between the two people, the parcel service and the government.
Between these factors, I assume they want the mobile app itself to also be pretty heavily locked down so that even if that nightclub bouncer wanted his phone to record your PIN or whatever it wouldn't work.
And no doubt it's also crossed some people's minds that if there was ever another pandemic, creating a sudden need for a new vaccine passport, it sure would be convenient to have an extensible national ID system....
