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.
Very likely I would say no. And that's why the home made crypto.
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.
Very likely I would say no. And that's why the home made crypto.
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. :)
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.
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.
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.
> 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-llcpThere 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 always thought only a subset of the capabilities of Java Cards were available in NFC mode due to power restriction reasons.
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).
There are many electronic ID systems in EU already and none of them have homegrown crypto...
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.
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-...
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.