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

From: Mingliang Pei <[email-masked]>
Date: Sat, 1 Jul 2017 01:57:41 +0000

Hi Anders,

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,

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