[Rats] TUDA. Re: Two types of secure attestation

[Anders Rundgren <[e-mail]>]

On 2019-11-21 05:33, Smith, Ned wrote:
> The TUDA draft might satisfy session attestation semantics. There may be others.

Thanx Ned,

I took a peek in
https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/
and I had a hard time finding similarities.

Session based attestation is not targeting constrained devices but rather powerful environments like mobile phones.
The multi-step "Protected API" and transactional operation is the core.  The session time is typically limited to 10 minutes.

Although it wasn't considered, TEEP could have been a candidate for this scheme as well:
https://cyberphone.github.io/doc/research/unified-tee-management-api.pdf

Anders

> 
> *From: *Anders Rundgren <[e-mail]>
> *Date: *Wednesday, November 20, 2019 at 8:11 PM
> *To: *"Smith, Ned" <[e-mail]>, Kathleen Moriarty <[e-mail]>, Laurence Lundblade <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Rats] Two types of secure attestation
> 
> And then you have the outcome/action of an attestation which I guess currently is "Pass" or "Fail".
> 
> As shown in https://cyberphone.github.io/doc/research/session-based-remote-attestation.pdf "Pass" may very well return a more sophisticated result, enabling a protected API in a session a bit similar to TLS.
> 
> Anders
> 
> On 2019-11-20 22:11, Smith, Ned wrote:
> 
>     There are some misrepresentations in the analysis below (I’ll comment inline below using [nms] delimiters). In general, I don’t see attestation types as being binary. Dave Thaler’s chart / truth table in another thread seems to suggest this as well given there are many different types of attesting environments (aka roots of trust).
> 
>     It might make sense to have discussion around claims that apply to attesting environments vs. claims that apply to attested environments? The important security property of attesting environments is they often are regarded as “trusted” meaning there isn’t some other attesting environment that vouches for it.
> 
>     Associating claims to attesting environments often takes a different from attestation (as represented by the roles / arch models); namely using certificates issued by product vendors (what the arch has called ‘asserters’). Certificates typically contain identity claims but could contain additional claims. Vendors could also sign assert claims by signing a document that asserts them. These could be manifests, attribute certs, identity certs with claims extensions and possibly even JWT/CWT (tokens). I haven’t seen a use case for vendor issued tokens however. Possibly PKI will transition from X.509 based to Token based at some point in the future, but I expect it will take a while. Vendors issuing (signing) manifests seems reasonable since many already create manifests for software distribution also called packages / bundles. The workflow for ‘reference values’ would not be much different than for creating a SW update manifest.
> 
>     *From: *RATS <[e-mail]> <mailto:[e-mail]> on behalf of Kathleen Moriarty <[e-mail]> <mailto:[e-mail]>
>     *Date: *Tuesday, November 19, 2019 at 6:00 PM
>     *To: *Laurence Lundblade <[e-mail]> <mailto:[e-mail]>
>     *Cc: *"[e-mail]" <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>     *Subject: *Re: [Rats] Two types of secure attestation
> 
>     Hi Laurence,
> 
>     I read your message as there only being 2 types of attestation as opposed to what you stated in your follow on email, which better maps to the restricted set in your first message.
> 
>     Thanks,
> 
>     Kathleen
> 
>     On Tue, Nov 19, 2019 at 8:07 PM Laurence Lundblade <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         Hi Kathleen,
> 
>         Not sure I’m following your thought completely.
> 
>          From what I know of Authenticated Boot, the code signing formats are usually proprietary and idiosyncratic. The first stages of it are likely in true ROM (chip metal layer) and can be very architecture and system specific and would not use CoSWID or EAT.
> 
>         My comments below are about getting a system booted up to state where it known to behave as desired.
> 
>         Once it is up then signed CoSWIDs in EATs would come into play. They can be trusted because the attester and system SW known to have booted up correctly. Knowing who signed some SW listed in a CoSWID is only of value if you know the system SW did signature checking when it loaded the SW it listed. For example, everyone knows how Android app signing works, so listing the signer of an Android app is good useful information.
> 
>         Hope that makes sense in relation to your comment.
> 
>         LL
> 
> 
> 
> 
>             On Nov 19, 2019, at 10:35 PM, Kathleen Moriarty <[e-mail] <mailto:[e-mail]>> wrote:
> 
>             Hi Laurence,
> 
>             Where does the code signing example fit in that you gave as it's not really an attestation, but could be useful in the format of an EAT/CWT?   This questions considers the CoSWID discussion as well as another example you had in your slides later (which was really the same) on just validating the code was signed by the expected private key?  Should that be called an attestation or just using the format for signing?  You might add claims in above what's in the CoSWID and use the nesting of EAT/subdomains as well as perform remote verification.
> 
>             Thanks,
> 
>             Kathleen
> 
>             On Tue, Nov 19, 2019 at 8:26 AM Laurence Lundblade <[e-mail] <mailto:lgl@island-resort..com>> wrote:
> 
>                 Fundamentally, I think there are two ways that an attestation verifier comes to know that a device / entity is running approved SW and will behave as desired.
> 
>                 *TPM based*
> 
>                 ·Originates in the PC world where the end user had to be able to choose the system SW
> 
>                 [nms] Not sure what relevance to attestation should be ascribed because of how TPMs originated.
> 
>                 ·Has a TPM that performs a general measuring function
> 
>                 §Has an attestation signing key for signing measurements that is kept secret by the TPM
> 
>                 oTPM is generic as it can be used for PC’s, routers, IoT devices
> 
>                 [nms] Profiles for how to adapt TPM for use in specific platform classes is generally required.
> 
>                 ·Authenticated boot is optional
> 
>                 [nms] I think the industry also uses the term ‘secure boot’. TPM supports attestation (of the boot sequence) while a secure boot approach doesn’t imply attestation is needed/used.
> 
>                 [nms] Boot behavior is more a property of the Root of Trust for Measurement (RTM) than a TPM. There are many types of RTM technology most simply it is a boot ROM.
> 
>                 ·Uses a staged boot architecture where each stage must measure (hash) the following stage
> 
>                 [nms] Boot architecture is determined by the type of device / platform not the TPM. Staged boot sequences are fairly common across the industry. Hence the term ‘bootstrap’.
> 
>                 oHashes fed into the TPM
> 
>                 oTPM generates the attestation of the registers holding the hashes
> 
>                 ·Device cost raised by cost of TPM part
> 
>                 [nms] Not sure how this is relevant to RATS
> 
>                 ·The verifier must run a parallel set of measurements (hashes)
> 
>                 oVerifier is complex
> 
>                 [nms] as compared to what?
> 
>                 *Authenticated Boot based*
> 
>                 ·Origins in mobile phone, TEE and DRM world where the user can NOT choose the system SW
> 
>                 ·Authenticated boot is required
> 
>                 oUses a boot ROM that really is a ROM, probably in silicon (not flash), that can NOT be changed
> 
>                 [nms] This is true for platforms using a TPM as well.
> 
>                 oBoot ROM verifies the SW that is loaded, particular the top privilege (e.g. kernel) SW
> 
>                 [nms] Verification implies the ability to determine boot code integrity. This is common to platforms that use a TPM.
> 
>                 oA good implementation has anti-rollback to prevent old versions of SW from being run
> 
>                 ·Has an attestation signing key that is programmed in fuses or possibly in flash
> 
>                 [nms] This is commonly true for TPM based attestation implementations.
> 
>                 oHas a HW block that prevents access to the attestation key unless authenticated boot succeeds
> 
>                 [nms] This is also true for solutions that wish to implement secure boot using a TPM.
> 
>                 oOnly top privilege SW can use it
> 
>                 [nms] TPM attestation keys have restrictions on use as well.
> 
>                 ·Attestations are created in the top-privilege SW
> 
>                 oSimply signing a nonce proves the device is running approved SW
> 
>                 [nms] The security properties of the signing key (attestation key) are a function of the claims that the manufacturers make about the environment that protects the key. This is true for TPM as well as any other root of trust / attesting environment.
> 
>                 oEasy to add other claims in —> EAT
> 
>                 [nms] relative to what?
> 
>                 ·Device cost raised by need for secure key provisioning in the factory
> 
>                 ·Verifier is very simple
> 
>                 oJust needs to verify the signature and nonce
> 
>                 [nms] The verifier is also integrated into the boot code. These verifiers need to be provisioned with boot state policies and so forth. Secure boot is an example of the combining of Attester and Verifier roles.
> 
>                 Both provide acceptable security for their use cases and are broadly in use.
> 
>                 RATS needs to support both.
> 
>                 [nms] In what ways does RATS not support both?
> 
>                 LL
> 
>                 _______________________________________________
>                 RATS mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/rats
> 
> 
>             -- 
> 
>             Best regards,
> 
>             Kathleen
> 
>             _______________________________________________
>             RATS mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/rats
> 
> 
>     -- 
> 
>     Best regards,
> 
>     Kathleen
> 
> 
> 
>     _______________________________________________
> 
>     RATS mailing list
> 
>     [e-mail]  <mailto:[e-mail]>
> 
>     https://www.ietf.org/mailman/listinfo/rats
> 
> 
>