Components: A secret management system about freenet-core HOT 4 CLOSED

We can close this as we have a sample test component now in main, most remaining changes have to do with fleshing out the API and will be fixed when we move to flatbuffers.

from freenet-core.

An example on how this may be used by the email application:

Email Decentralized App

User gets contract key of email application, visits it in web browser via proxy
Create public/private keypair to represent this user’s inbox
Does the app create the keypair, or does the component create it on initialization?
Application requests that node create component to store and manage access to private key
Application requests component creation, provides component wasm code + parameters
Application and component are aware of each-other so they can trust messages received from the other
Node can assure application and component that they’re talking to each other
User wants to send an email
Composes email using application UI, hits “send”
Application sends message to component requesting that the component sign it, which the component does because it knows and trusts the application
Application adds signed message to inbox contract of the intended recipient (after obtaining a antiflood token)

—-------------------

Email application installed
App requests creation of email component to store private key
App sends message to component:
App — [CreateInboxRequest] → Component
Component —- [SetSecret(“inbox_key”, private_key)] —> NODE
Component — [CreateInboxResponse(publicKey)] —> App
—- app wants to send an email
App — [PleaseSignMessage(message_content)] —> Componen
Component —- [GetSecretRequest(“inbox_key”)] —-> Node
Node —- [GetSecretResponse(“inbox_key”, private_key)] —> Component
Component —- [MessageSigned(signature)] —> App

from freenet-core.

Note to self:

• Add a registering command for new components
• On the API on the node provide a call for requesting secure random bytes
  • This takes care of the item: "Components need a way to generate secure random data, eg. for keypair generation"
• When components are created (before registering), the necessary keys are generated and provided by the source of the component (via the API).
• The current interface is very generic, we are not expecting any certain template for user interaction and just dealing with raw bytes we can force this later on (potentially separating content from representation so we don't end up trapping ourselves with an implementation like HTML)
  • re. "Current user interaction is limited to questions with multiple-choice answers; this is probably too restrictive"
  • before we are done with this issue we need at least to implement one working version of this though; my general idea is to decompose the content/values (we will be sending those in some standard format in the messages, something like a json) from how they are represented (notifications channels can be registered in the node on initialization, this will make it easier to use different kinds of channels based on the platform, user preferences, etc.). The notification channels will have to be able to implement a certain interface (like receiving messages, etc.). Need to define this better.

from freenet-core.

Some additional changes that we will have to take ind mind:

• Limit the creation of components per application to 10mb (by default, configurable) worth of secrets stored.
• Ask for confirmation before deleting any secrets because of lack of space, since it contains sensible data (like private keys).
• Add versioning.
• In the future, take in mind any synchronization problems that may happen when using a distributed system as the location where secrets are stored.

from freenet-core.