Signature Record Type Definition

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found. 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

The NDEF signing process

File:NDEF Signing.png
NFC Forum Signature RTD Signing Process

Referring 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

File:NDEF Verifcation.png
NFC Forum Signature RTD NDEF Verification

Referring 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

The 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

The 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

The 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

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.