Sunbird RC as a PKI Infrastructure

[ChakshuGautam]

Should RC allow for Entities to be signing authorities and manage their own keys?

Example Use Cases

1. A teacher signing a credential for a student.
2. Ability for an Entity to manage their key pairs either on persona wallet/hardware or store it with them.
3. As an extension to 2, the ability to deactivate/disable older keys for use of signing certificates.

Specific Priority Use Cases

1. Issuer security - Meena, a private school teacher started enrolling students and issuing enrolment credentials to them. After she enrolled 10 students and while she was logged into the enrolment portal, the enrolment flow was not starting for her. After a few minutes she was seeing new students being added from her account in the school. Meena quickly changed her account password but this suspicious activity continued. Meena then called the state helpline and the technology team was able to resolve this.

   In this case Meena's private key for issuing credentials was leaked. These keys will be stored centrally and therefore the person managing the private key store will be able to issue her a new private key.

   Today, this is expected to be a central private key store. However, going forward there may be a need by power users in the private school ecosystem who prefer and want to manage their own private keys.

Additional Notes

I have gone through the current implementation and this does not cover some of the use cases mentioned above.

As an aside, we should cover the security guidelines as part of the documentation on how to manage the keys.

[surendrasinghs]

How often do we foresee the leaking of private keys happening? Who might be able to do this? Do we expect users (teachers or school principal) to manage their keys by themselves? What's the priority of this use-case? @sukhpreetsamagra

I would think this complexity be best hidden from users.

[sukhpreetssekhon]

Thanks for the comment Suren.

Clarification - We expect private schools to have their own key, but centrally managed. While this may be hidden from the users, we need to have a method to secure and address this.

[ChakshuGautam]

1. High-level requirements

• To support a large number of issuers, RC should allow a key management solution for the issuers
• Issuer interface should not expose the complexity behind but should allow features like key rotation, revoke, etc
• RC should have an internal vault to manage keys securely. Ability to use an external/existing vault will be a good addition too.

2. Implementation Design

2.1 Key Management APIs

There are wrapper APIs to support various vaults behind the scene.

POST keys/generate

{
	"entityId": "<entity-id>",
	"keyType": "Ed25519VerificationKey2018 | …",
	"name": "default | …"
}

POST keys/:entity/rotate

Generate a new key and add it to the .well-known URI

GET :entityId/.well-known/jwks

Returns all keys for an entity. Fulfills the need for an ID resolver for now.

POST keys/:key_ref/revoke

This is a potentially dangerous thing. Updating the JWKS to include a flag called revoked might be a better way to manage this.

2.2 KeyStore - Hashicorp Vault as a PKI Store

Abstracted storage APIs that allow connecting to any Vault

• getKey(keyRef)
• setKey(keyRef, keyValue)
• limitAccessToKey(keyRef, [limitations])
• revokeKey(keyRef)
  …

2.3 Security Considerations

• A Zero Trust Architecture when connecting to Vault Microservice
• Private Keys should be stored separately from the public keys with different accesses.
• Private Keys should be accessible only by the signing service (ideally should be segregated from all other processes)
• Exporting the private keys is not allowed with an additional 2FA KYC/Auth first
• Downloading of keys to wallet should be allowed

[pramodkvarma]

There must be some open source implementations that we can integrate with? First is to ensure an open service interface is created to allow plug and play with various vault services given some adopters will choose to use an HSM or other commercial services. Can @tejash-jl and you get on a call with Sasi (security architect) and have a quick discussion before we start any work?

[tejash-jl]

Sure @pramodkvarma.

[ChakshuGautam]

We are also evaluating the following PKI. Everyone, please let your thoughts on this

1. Amazon KMS
2. eMudhra

The parameters that we are looking into are

1. Easy Integration - simple signing APIs
2. Safety
3. Security - No transmission of Private key over the wire
4. Horizontal Scalability

cc:- @suresh12 @surendrasinghs @parthlawate @coolbung @rahul101001000

[gsasikumar]

To solve this better can anyone explain how the teacher gets her/his key pair? I mean let's speak more about onboarding if this is clear then the remaining might be easier. Also can this not be done with a private key on the phone instead of key central storage?

How is the teacher's key published? Are we relying on did resolution for teachers' key or it's just a PKI?

[pramodkvarma]

Maybe easier for all of you to get on a call and then publish back the summary here for the rest of the community? @ChakshuGautam @gsasikumar @sukhpreetsamagra @surendrasinghs @tejash-jl

[gsasikumar]

How does the teacher gets her/his key pair? Also can this not be done with a private key on the phone instead of a central storage?

How is the teacher's key published? Are we relying on did resolution for teachers' key or it's just a PKI?