Redesign the secure element interface to support wrapped key storage

[gilles-peskine-arm]

Make a new design pass over the secure element interface.

Goals:

• Make it simpler to write drivers, based on experience gained from the first drafts.
• Support keys which the secure element does not store, but exports in a wrapped form, and which the generic code stores.
• Support volatile secure element keys (encoding of lifetimes in Define some structure for lifetime values ARMmbed/mbed-crypto#358).

Deliverable of this task: an architecture plan, possibly with a prototype. Robust code and tests are out of scope.

[gilles-peskine-arm]

I consider this task fulfilled by the unified driver interface. Although the pull request introducing the specification is not merged yet and the architecture document is still incomplete, we've decided to adopt this approach. This task is no longer useful for planning purposes, and we should continue with more specific tasks.

Make it simpler to write drivers, based on experience gained from the first drafts.

At this stage, “simpler” can only be subjective. There's still work to be done, especially related to storage and resilience. But I do think this is headed in the right direction.

Support keys which the secure element does not store, but exports in a wrapped form, and which the generic code stores.

The unified interface was designed with this possibility in mind.

Support volatile secure element keys (encoding of lifetimes in ARMmbed/mbed-crypto#358).

This is being done in #3288 for the current SE driver interface. The unified interface was designed with this possibility in mind.