Subject: Re: [Teep] [EXT] OTrP Proposal - Chunking Data to Conserve RAM

From: Anders Rundgren <[email-masked]>
Date: Sun, 2 Jul 2017 08:42:59 +0200

On 2017-07-01 03:57, Mingliang Pei wrote:
> Hi Anders,

Hi Ming,

> 
> I am not sure I quite follow the synergy here. A TA management message
> protocol between a TEE and TAM uses a ³keygen² and key store scheme that
> sounds to be in a device side? I may need your help to show how the dots
> connect when we meet. Thanks,

I probably made the message unnecessarily confusing by mentioning SKS/KeyGen2.

The core idea is simply creating a shared secret and then use that during a "session"
that may consist of any number of steps where the last step would be "commit".

However, If OTrP only needs single, fully atomic requests, there would be
little point with such an arrangement although the ability to conserve
RAM (through chunking) and enabling COSE and JSON variants without
changing the the TEE side of the OTrP driver might be useful.

Lets say that you want to deploy a 1Mb TA.  Using the current approach
you would need like 1.4Mb of RAM to do that.  Using a chunking scheme
you would be good with less than 64Kb.  If we are talking mobile devices
only this is a no-issue, for other devices it might be.

Anders

> 
> Ming
> 
> On 5/23/17, 8:11 AM, "TEEP on behalf of Anders Rundgren"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>> Hi fellow TEEers,
>>
>> As some of you know I have been working for a long time on a concept
>> coined SKS/KeyGen2 which is about using a TA (or HW) as a universal
>> keystore and then be able managing keys in an E2ES (End to End Security)
>> fashion over the Web.
>>
>> Since the data structures you can create with the management protocol
>> (KeyGen2) are arbitrary complex, a naive approach would require an
>> equally arbitrary amount of RAM.  Since RAM vs FLASH/ROM typically differ
>> with a factor of 10 or more, I simply had to come up with a better
>> solution.
>>
>> The solution I found was to creating a _session_key_ and do things in
>> _steps_.  This allows the system to use a non-encrypted (but MACed) API
>> and only encrypt data which absolutely needs encryption. Another benefit
>> is that the protocol can work on (what appears to be) a high level
>> including aggregation of API calls.
>>
>> https://cyberphone.github.io/doc/security/keygen2.html#Sample_Run
>>
>> Are there downsides to this you may wonder?  Of course, _all_ solutions
>> have such :-)
>> If a session is abruptly terminated you may end up with a bricked system.
>>
>> Workaround:  The SKS (Secure Key Store) builds on a transaction concept
>> so that nothing is "committed" (inside of it) until the last call has
>> been _successfully_performed_.
>>
>> There's another important benefit of the session key approach: Format
>> independency on the protocol side since the API only needs to process
>> low-level binary. That is, OTrP could be dressed in JSON and CBOR without
>> _any_ protocol/API level adjustments.
>>
>> This is not only a nice theory, a public PoC using a "soft" SKS is
>> available for anybody having 5-10 minutes to spend:
>> https://clicktime.symantec.com/a/1/ggAdops3Ydf6C9-yDs0VOyEO1bahJhu00SU0rkD
>> Qem4=?d=lqPhCwVyemhl49G8CGjmJsn-ffcjyzl4WQrsBBXcp8w6tchxzYobQKJee4EhwuaUEm
>> PvNUyKZU1LNAGZrOscSxXqstjbJKshzS1QyOFF972izeB8gvyEfTxYVxTJM-CL2Ovs-K1xl2FZ
>> AHAuAfwJW5AbdOK0W6G8WdzLthzwSy9NmwEwlfzPRxk6sUOtXIIZntC1VVDgdOGfhZDPd-4vw9
>> RFkB3j799aGao4kYN9tiGrLJaLy7ygb42P6iwKT_BBuM8xRWERdoXSXbq74l9usUzM4c-2Z9Jm
>> 3yLnhoFfFi_WoGu2aginpoP0o7zCiVP5zPRcxCP2ybRbpnEtXA0FA0RWhSB2rkltyjZ2MHUT1i
>> qP8kTPguh5ymOI1sQXjN5RQWrz7cUKt1rjL1CUxw%3D%3D&u=https%3A%2F%2Ftest.webpki
>> .org%2Fwebpay-merchant
>> https://clicktime.symantec.com/a/1/TqDNusTIhT9HMVLmftjqYel-a4Byq3bZdlSHOyR
>> ZY2o=?d=lqPhCwVyemhl49G8CGjmJsn-ffcjyzl4WQrsBBXcp8w6tchxzYobQKJee4EhwuaUEm
>> PvNUyKZU1LNAGZrOscSxXqstjbJKshzS1QyOFF972izeB8gvyEfTxYVxTJM-CL2Ovs-K1xl2FZ
>> AHAuAfwJW5AbdOK0W6G8WdzLthzwSy9NmwEwlfzPRxk6sUOtXIIZntC1VVDgdOGfhZDPd-4vw9
>> RFkB3j799aGao4kYN9tiGrLJaLy7ygb42P6iwKT_BBuM8xRWERdoXSXbq74l9usUzM4c-2Z9Jm
>> 3yLnhoFfFi_WoGu2aginpoP0o7zCiVP5zPRcxCP2ybRbpnEtXA0FA0RWhSB2rkltyjZ2MHUT1i
>> qP8kTPguh5ymOI1sQXjN5RQWrz7cUKt1rjL1CUxw%3D%3D&u=https%3A%2F%2Fplay.google
>> .com%2Fstore%2Fapps%2Fdetails%3Fid%3Dorg.webpki.mobile.android
>>
>> The next [anticipated] step on this project is transcending cryptographic
>> keys to become first-class OS objects like Files, Processes, Users, etc.
>> which I recently presented at Linaro Connect in Budapest.
>>
>> Cheers,
>> Anders
>> https://clicktime.symantec.com/a/1/7X7OUEGaQxNzyiGR0vsp-Np1LfXYKBdTf3Omeej
>> uqdI=?d=lqPhCwVyemhl49G8CGjmJsn-ffcjyzl4WQrsBBXcp8w6tchxzYobQKJee4EhwuaUEm
>> PvNUyKZU1LNAGZrOscSxXqstjbJKshzS1QyOFF972izeB8gvyEfTxYVxTJM-CL2Ovs-K1xl2FZ
>> AHAuAfwJW5AbdOK0W6G8WdzLthzwSy9NmwEwlfzPRxk6sUOtXIIZntC1VVDgdOGfhZDPd-4vw9
>> RFkB3j799aGao4kYN9tiGrLJaLy7ygb42P6iwKT_BBuM8xRWERdoXSXbq74l9usUzM4c-2Z9Jm
>> 3yLnhoFfFi_WoGu2aginpoP0o7zCiVP5zPRcxCP2ybRbpnEtXA0FA0RWhSB2rkltyjZ2MHUT1i
>> qP8kTPguh5ymOI1sQXjN5RQWrz7cUKt1rjL1CUxw%3D%3D&u=https%3A%2F%2Fpriorart.ip
>> .com%2FIPCOM%2F000215433
>>
>> _______________________________________________
>> TEEP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/teep
>