[Tracker] Use private keys within secure element rather than in memory

[cpswan]

Is your feature request related to a problem? Please describe.

We generally work with private keys that have been copied from a secure element into memory, but this isn't best practice, and isn't possible with properly implemented hardware generated keys e.g. IoT SAFE.

Describe the solution you'd like

Delegate operations using private keys to hardware based elements where possible so that we don't need to copy keys into memory.

MVP description

We shall modify the HRO2 demo (nee MWC demo) such that it uses a keypair generated in the ZARIOT supplied Kigen manufactured SIM card using GSMA IoT SAFE.

NB that this will also be dependent on #755 as IoT SAFE makes use of ECC keys.

High-level tasks (please add additional tasks here!)

• [x] Initial design and implementation of at_chops interface
• [ ] High-level marketing / launch plan (how do we talk about this, why it's important, why it's cool, how to use it, etc)
  • [ ] Annouce at IoT World Solutions Congress Barcelona Jan 31- Feb 1
• [ ] Integrate the at_signing work into the at_chops package
• [ ] Refactor client-side packages to use new at_chops interface
  • [x] at_lookup
  • [x] at_client
  • [x] at_client_mobile
  • [ ] at_onboarding_cli
  • [ ] at_onboarding_flutter
• [ ] Implement at_chops architecture in the Java SDK
• [ ] Spike an implementation which actually uses a secure element for some operations (spike should implement the MVP defined above)
• [ ] "How to" guides on docs.atsign.com
• [ ] Text or video (or both) content for posting on social or our website

[gkc]

As a first step on this journey, we need to

• isolate all of the operations that depend on private keys into an interface (at-chops)
• inject an instance of at_chops into the various moving parts of the client
  • So every piece of code that needs an operation that depends on private keys is using an instance of at_chops
• replace all current direct usages of keys in those various moving parts (AtClient, AtLookup, ...), calling methods on the interface instead
• and then ensure we never put the private keys into program space except hidden behind that interface

This structural change will set us up to build other implementations of the interface which delegate operations to secure elements without requiring any core code changes.

[gkc]

More on this:

• The interface should live in a new package called at_chops (Cryptography and Hashing OPerationS) which we can place in the at_libraries repo. It needs to live in its own package as it will be used by multiple other packages including at_client, at_secondary_server, at_lookup, at_onboarding_cli
• To the extent that is reasonably possible (e.g. not prohibitively time-consuming) , we should make our interface compatible with the TPM2.0 spec. There are number of full or partial implementations of software libraries around the TPM 2.0 spec listed here. (Note: The WolfTPM library looks very promising, implemented in C(++) supporting many platforms.) which will help us define our interface.
• [Note: It is not essential that this interface be a perfectly compatible match with the TPM 2.0 spec. Initially our implementation of this interface will operate the same way as all our current stuff does - i.e. within program space.
• As soon as we reasonably can, we will provide another implementation of the interface which talks to an underlying library (e.g. WolfTPM) which in turn integrates with an actual TPM.
• Another implementation could delegate some operations to whatever hardware elements are available, but handle others in program space.

[gkc]

Applying the 'Urgent' label as the first part of this (creating the interface and restructuring code to use it) is a prerequisite for for multiple other platform improvements.

[gkc]

I removed the urgent label again as I guess it's not currently truly urgent. It is very very important though.

[gkc]

8SP for PR49 to design / define the interface, get it reviewed and agreed on arch call(s)

[gkc]

Removing 8SP label as this issue will be the top-level aggregator of the various other tickets we will create

[cpswan]

Added MVP description section to root comment for this issue.