Draft: draft-ietf-rats-architecture

Commentary: This is to partially 
 In section 4.2 there is a list of " places an attesting environment can exist " that is limited . The text should be softened to say the list is only examples and there is no formal limitation or requirement on the security of an Attester . There should probably be a detailed description of Attester security in the document , but it should be in Security Considerations . This seems like a glaring omission from Security Considerations . 
 The considerations were n't the extent of the issue . There is still text in 4.2 that I think needs changing .
Paragraph (version B):
Implementers need to pay close attention to the isolation and
protection of the Attester and the factory processes for provisioning
the Attestation Key Material.  When either of these are compromised,
the remote attestation becomes worthless because the attacker can
forge Evidence.
Paragraph (version B):
Remote attestation applies to use cases with a range of security
requirements, so the protections discussed here range from low to
high security where low security may be only application or process
isolation by the device's operating system and high security involves
specialized hardware to defend against physical attacks on a chip.
Paragraph (version B):
It is assumed that the Attester is located in an isolated environment
of a device like a process, a dedicated chip a TEE or such that
collects the Claims, formats them and signs them with an Attestation
Key. The Attester must be protected from unauthorized modification to
ensure it behaves correctly.  There must also be confidentiality so
that the signing key is not captured and used elsewhere to forge
evidence.
Paragraph (version B):
In many cases the user or owner of the device must not be able to
modify or exfiltrate keys from the Attesting Environment of the
Attester.  For example the owner or user of a mobile phone or FIDO
authenticator is not trusted.  The point of remote attestation is for
the Relying Party to be able to trust the Attester even though they
don't trust the user or owner.
Paragraph (version B):
Some of the measures for low level security include process or
application isolation by a high-level operating system, and perhaps
restricting access to root or system privilege.  For extremely simple
single-use devices that don't use a protected mode operating system,
like a Bluetooth speaker, the isolation might only be the plastic
housing for the device.
Paragraph (version B):
At medium level security, a special restricted operating environment
like a Trusted Execution Environment (TEE) might be used.  In this
case, only security-oriented software has access to the Attester and
key material.
Paragraph (version B):
For high level security, specialized hardware will likely be used
providing protection against chip decapping attacks, power supply and
clock glitching, faulting injection and RF and power side channel
attacks.
Paragraph (version B):
Attestation key provisioning is the process that occurs in the
factory or elsewhere that establishes the signing key material on the
device and the verification key material off the device.  Sometimes
this is referred to as "personalization".
Paragraph (version B):
One way to provision a key is to first generate it external to the
device and then copy the key onto the device.  In this case,
confidentiality of the generator, as well as the path over which the
key is provisioned, is necessary.  This can be achieved in a number
of ways.
Paragraph (version B):
Confidentiality can be achieved entirely with physical provisioning
facility security involving no encryption at all.  For low-security
use cases, this might be simply locking doors and limiting personnel
that can enter the facility.  For high-security use cases, this might
involve a special area of the facility accessible only to select
security-trained personnel.
Paragraph (version B):
Cryptography can also be used to support confidentiality, but keys
that are used to then provision attestation keys must somehow have
been provisioned securely beforehand (a recursive problem).
Paragraph (version B):
In many cases both some physical security and some cryptography will
be necessary and useful to establish confidentiality.
Paragraph (version B):
Another way to provision the key material is to generate it on the
device and export the verification key.  If public key cryptography
is being used, then only integrity is necessary.  Confidentiality is
not necessary.
Paragraph (version B):
In all cases, the Attestation Key provisioning process must ensure
that only attestation key material that is generated by a valid
Endorser is established in Attesters and then configured correctly.
For many use cases, this will involve physical security at the
facility, to prevent unauthorized devices from being manufactured
that may be counterfeit or incorrectly configured.