> 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:

* https://en.wikipedia.org/wiki/Java_Card

There is nothing constrained about modern smart cards: it's just a matter of how much you want to spend on the card and its capabilities.

Smartcard and NFC are two different beast.

The fashion for Smartcard is over, mainly due to the necessity of specialized reader.

The wind blows in favor of NFC cards & badge because they are smartphone compatible. But these comes with limitations.

Aren't these cards using NFC also running Java, just like most (all?) smartcards?

NFC doesn't preclude TLS:

> 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?

* https://github.com/Yubico/yubikit-ios/issues/5 (functionality added)

> 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.

* https://ieeexplore.ieee.org/document/6867565

> 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.

* https://eudl.eu/pdf/10.1007/978-3-642-32320-1_30

    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".

* https://datatracker.ietf.org/doc/html/draft-urien-tls-llcp

It's definitely possible: eSIM provisioning uses TLS too, as far as I know (between the eSIM chip and the provisioning service).

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.

Interesting thank you.

I always thought only a subset of the capabilities of Java Cards were available in NFC mode due to power restriction reasons.

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?

There are many electronic ID systems in EU already and none of them have homegrown crypto...

> Why not do the same thing credit cards or access smartcards do?

I think you would be surprised how bad the security on these system is.

The credit card security rely mainly on the ability of the bank to rollback in case of "shit happened" and in the terminal itself.

Probably not something you want to see to protect against identity thief nation wide.

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].

[1] https://artsandculture.google.com/story/roland-moreno-s-ubiq...

[2] https://www.thalesgroup.com/en/markets/digital-identity-and-...

[3] https://computer.rip/2023-09-03-plastic-money.html

> 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.

Yeah - your compute budget is measured here in microjoules

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.

How about EC signatures?

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.

Both. Newer digital tachograph cards use ECC signatures for signing gen2 smart tachograph data. Gen1 used RSA.