Docs: Compare authentication options in attestation token
Compare the symmetric and asymmetric crypto algorithm
based token authentication in initial attestation
service.
Change-Id: Ia2f4469d43e84e29a015d391c439818e39829dd5
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
diff --git a/docs/reference/services/tfm_attestation_integration_guide.rst b/docs/reference/services/tfm_attestation_integration_guide.rst
index 2c848e2..d3457cd 100644
--- a/docs/reference/services/tfm_attestation_integration_guide.rst
+++ b/docs/reference/services/tfm_attestation_integration_guide.rst
@@ -539,6 +539,53 @@
correct) and there are no other data entries. Its default value depends on
the BL2 flag.
+***************************************************************************
+Comparison of asymmetric and symmetric algorithm based token authentication
+***************************************************************************
+The symmetric key based authentication requires a more complex infrastructure
+for key management. Symmetric keys must be kept secret because they are
+sensitive asset, like the private key in case of asymmetric cryptographic
+algorithms. The main difference is that private keys are only stored on
+device, with proper hardware protection against external access, but symmetric
+keys must be known by both party (device and verifier), so they must also be
+stored in a central server of a relying party (who verifies the tokens).
+If keys are revealed then devices can be impersonated. If the database with
+the symmetric keys becomes compromised then all corresponding devices become
+untrusted. Since a centralised database of symmetric keys may need to be network
+connected, this can be considered to be a valuable target for attackers. The
+advantage of ECDSA based token authentication is that sensitive assets is only
+stored one place (in the device) and only one unique key per device. So if a
+device is compromised then only that single device become untrusted. In this
+case, the database of the relying party contains the corresponding public keys,
+which are not considered to be a confidential assets, so they can be shared with
+anybody. This shows the main advantage of asymmetric based authentication,
+because verification of attestation tokens can be done by a third party,
+such as cloud service providers (CSP). Thus Device Maker (DM) or Chip Maker (CM)
+does not need to operate such a service.
+
++-------------------------+-----------------------------------------+-----------------------------------------+
+| | Symmetric | Asymmetric |
++=========================+=========================================+=========================================+
+| Authentication mode | HMAC over SHA256 | ECDSA P256 over SHA256 |
++-------------------------+-----------------------------------------+-----------------------------------------+
+| Supported APIs | - psa_initial_attest_get_token(..) | - psa_initial_attest_get_token(..) |
+| | - psa_initial_attest_get_token_size(..) | - psa_initial_attest_get_token_size(..) |
+| | | - tfm_initial_attest_get_public_key(..) |
++-------------------------+-----------------------------------------+-----------------------------------------+
+| Crypto key type in HW | Symmetric key | ECDSA private key (secp256r1) |
++-------------------------+-----------------------------------------+-----------------------------------------+
+| Secrets are stored | Device and database | Device only |
++-------------------------+-----------------------------------------+-----------------------------------------+
+| Verification database | Same symmetric key | Public keys |
+| contains | | |
++-------------------------+-----------------------------------------+-----------------------------------------+
+| COSE authentication tag | COSE_Mac0 | COSE_Sign1 |
+| in the token | | |
++-------------------------+-----------------------------------------+-----------------------------------------+
+| Verification entity | CM or DM, who provisioned the | Can be anybody: third party provisioning|
+| | symmetric key | service, cloud service provider, CM, DM |
++-------------------------+-----------------------------------------+-----------------------------------------+
+
************
Verification
************