In near field communications the NFC Forum Signature Record Type Definition (RTD) is a security protocol used to protect the integrity and authenticity of NDEF (NFC Data Exchange Format) Messages. The Signature RTD is an open interoperable specification modeled after Code signing where the trust of signed messages is tied to digital certificates.[1]
Signing NDEF records prevents malicious use of NFC tags (containing a protected NDEF record). For example, smartphone users tapping NFC tags containing URLs. Without some level of integrity protection an adversary could launch a phishing attack. Signing the NDEF record protects the integrity of the contents and allows the user to identify the signer if they wish. Signing certificates are obtained from third party Certificate Authorities and are governed by the NFC Forum Signature RTD Certificate Policy.
How it works
editThe NDEF signing process
editReferring to the diagrams. An author obtains a signing certificate from a valid certificate authority. The author's private key is used to sign the Data Record (text, URI, or whatever you like). The signature and author's certificate comprise the signature record. The Data Record and Signature Record are concatenated to produce the Signed NDEF Message that can be written to a standard NFC tag with sufficient memory (typically on the order of 300 to 500 bytes). The NDEF record remains in the clear (not encrypted) so any NFC tag reader will be able to read the signed data even if they cannot verify it.
| Data Record | Signature Record |
|---|---|
| NDEF Record | Signature, Certificate Chain |
The NDEF Verification Process
editReferring to the diagram. Upon reading the Signed NDEF Message, the Signature on the Data Record is first cryptographically verified using the author's public key (extracted from the Author's Certificate). Once verified, the Author's Certificate can be verified using the NFC Root Certificate. If both verifications are valid then one can trust the NDEF record and perform the desired operation.
Supported certificate formats
editThe Signature RTD 2.0 supports two certificate formats. One being X.509 certificate format and the other the Machine to Machine (M2M) Certificate format.[2] The M2M Certificate format is a subset of X.509 designed for limited memory typically found on NFC tags. The author's certificate can optionally be replaced with a URI reference to that certificate or Certificate Chain so that messages can be cryptographically verified. The URI certificate reference designed to save memory for NFC tags.
Supported cryptographic algorithms
editThe Signature RTD 2.0 uses industry standard digital signature algorithms. The following algorithms are supported:
| Signature Type/Hash | Security Strength (IEEE P1363) |
|---|---|
| RSA_1024/SHA_256 | 80 bits |
| DSA_1024/SHA_256 | 80 bits |
| ECDSA_P192/SHA_256 | 80 bits |
| RSA_2048/SHA_256 | 112 bits |
| DSA_2048/SHA_256 | 112 bits |
| ECDSA_P224/SHA_256 | 112 bits |
| ECDSA_K233/SHA_256 | 112 bits |
| ECDSA_B233/SHA_256 | 112 bits |
| ECDSA_P256/SHA_256 | 128 bits |
On the security of the Signature RTD
editThe Signature RTD 2.0's primary purpose is the protect the integrity and authenticity of NDEF records. Thus, NFC tag contents using the Signature RTD 2.0 is protected. The security of the system is tied to a certificate authority and the associated Certificate Chain. The NFC Forum Signature RTD Certificate Policy defines the policies under which certificate authorities can operate in the context of NFC. Root certificates are carried in verification devices and are not contained in the signature record. This separation is important for the security of the system just as web browser certificates are separated from web server certificates in TLS.
References
edit- ^ "Home - NFC Forum". NFC Forum.
- ^ "IETF - M2M Certificate format". IETF.