Re: [Teep] Security domain default 1-to-1 mapping to a TA proposal in TEEP

[Mingliang Pei <[e-mail]>]

There are multiple follow up discussion in the issue tracker. Here is a quick summary:

Andy described the value the SD currently provides, and values of the SP AIK.

"1. (SP AIK is used in) additional Encryption of TA / perso data (by the TAM or the SP)

The CreateSD response returned spaik public key. This could be used by either the TAM or the Service Provider (that sits behind the TAM) to encrypt a TA or personalization data, encrypted for that specific device. This provided a means where a ServiceProvider could be enabled to keep data (the TA and the perso data - which would typically contain sensitive per device info) hidden from the TAM. 

Is there value in this spaik? It offers protection when a Service Provider wants to maintain some independence from TAM and wants to keep the TA binary private from the TAM, and to be able to create secret ‘per device’ personalization data on the fly (that will be private from the TAM). 

2. SP AIK is used by a Client App to verify response information returned in a call getTAInformation

Is there value in the anonymous attestation? Assuming the getTAInfo response is signed, there is value in avoiding releasing the TEE certificate to the app – since releasing the TEE certificate to rich OS apps implies that Rich OS can get a unique device identifier (which has privacy or tracking concerns).

If the CreateSD was removed, it wouldn’t necessarily stop us from being able to have an spaik for the purposes of signing getTAInfo response. (might need to think about this a bit more). Maybe we need to think more about how the Rich OS can be sure that TA id xx really does come from the service provider that it thinks it comes from."

David W had a follow question why separate SP AIK is needed. Single AIK per device can work for the data encryption purpose to a device. There is no strong objection on this.

There was the GetTAInfo response signing per SP for privacy usage.

David T raise a question whether TEE certificate as a device identity itself needs to be hidden as Rich OS may filter it as it does for other device ID such as MAC address etc.

I considered that Rich OS doesn't have the security strength in dealing with TEE device ID filtering as what TEE is designed for. This would also add a burden to Rich OS to guard TEE certificate pharming by a Client App over devices. This privacy concern needs to be further discussed.

Andy, Dave W, and Dave T, please feel free to add or revise.

Thanks,

Ming

On 3/10/19, 11:30 PM, "TEEP on behalf of Mingliang Pei" <[e-mail] on behalf of [e-mail]> wrote:

    Thanks Ben, will do, Ming
    
    On 3/10/19, 9:58 AM, "Benjamin Kaduk" <[e-mail]> wrote:
    
        It would probably be good to get a summary of the discussion posted on the
        list once it's settled down, for archival purposes.
        
        -Ben
        
        On Fri, Mar 08, 2019 at 03:39:02PM +0000, Mingliang Pei wrote:
        > Thanks Andy, will follow up updates on the github, Ming
        > 
        > Sent from iPhone
        > 
        > ________________________________
        > From: Andrew Atyeo <[e-mail]>
        > Sent: Friday, March 8, 2019 1:42 AM
        > To: Mingliang Pei
        > Cc: [e-mail]
        > Subject: RE: Security domain default 1-to-1 mapping to a TA proposal in TEEP
        > 
        > Hi,
        > I have updated the github issue with my comments
        > https://clicktime.symantec.com/3UZcZZ4xTSsNvytS9paFjkp7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F7<https://clicktime.symantec.com/3DtasvM638D48u9sEW2edx47Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F7>
        > 
        > basically I understand that there are some deployment types that might prefer a simpler approach, but I want to make sure that we know what would be ‘lost’ by not having a SD that is created separately. It might be that for some deployments the loss is no problem, or it might be that there could be alternative ways to give the same functionality but without need for a separate createSD that are worth exploring.
        > The github issue (link above) hopefully explains this better.
        > 
        > Regards,
        > 
        > Andrew Atyeo
        > Security Architect
        > Intercede
        > Digital trust    people ǀ devices ǀ apps
        > Office: [phone]
        > https://clicktime.symantec.com/3VJerJ8soKqVyMNkw4JWG3s7Vc?u=www.intercede.com<https://clicktime.symantec.com/3Gqczp4aRiNtTy5rmhmPUeK7Vc?u=https%3A%2F%2Fwww.intercede.com%2F>
        > Legal Disclaimer <https://clicktime.symantec.com/3NQrLHmW1wfB1dzjQvLeV5f7Vc?u=https%3A%2F%2Fwww.intercede.com%2Fprivacy-cookies>
        > From: Mingliang Pei <[e-mail]>
        > Sent: 08 March 2019 02:00
        > To: Andrew Atyeo <[e-mail]>
        > Cc: [e-mail]
        > Subject: Security domain default 1-to-1 mapping to a TA proposal in TEEP
        > 
        > Hi Andy,
        > 
        > We are working on to close this issue #7: clarifying meaning of Security Domain (SD)
        > 
        > https://clicktime.symantec.com/3UZcZZ4xTSsNvytS9paFjkp7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F7<https://clicktime.symantec.com/3DtasvM638D48u9sEW2edx47Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F7>
        > 
        > We want to simplify it, and propose to create a SD per TA by default, without completely removing the SD for some existing use cases. It will be good to also have your input on the implications, considering you have more involved in this with a prior OTrP TAM POC implementation. Could you review the issue, and provide comments there?
        > 
        > Here is a quick recap on some discussion reasonings.
        > 
        > Historically we consider Security Domain as a first class entity in TEEP (OTrP). There have been some desires to simplify it, or not require it in the TEEP architecture as some use cases don’t use it as much as potential IoT use cases. On the other hand, we know that existing TEE implementations and other secure element related practices uses SD to isolate and associate protection boundary. There was some resource constraints on number of SDs that can be allocated in a TEE device.
        > 
        > To achieve broad support of both worlds, we consider to move to an “implicit” model as follows:
        > 
        > 
        >   *   One SD is created per TA when a TA is going to installed. This allows creation of TA without going through explicit SD creation and so on.
        >   *   The prior deletion of SD will delete all TAs within the same SD. Now each TA will be required to be explicitly deleted.
        > 
        > Thanks,
        > 
        > Ming
        > 
        
        > _______________________________________________
        > TEEP mailing list
        > [e-mail]
        > https://clicktime.symantec.com/3MCf2NsshWc1XzMuSUWKTSB7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
        
        
    
    _______________________________________________
    TEEP mailing list
    [e-mail]
    https://clicktime.symantec.com/3G4AynbCisPqc4EAAhpG8Cq7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep