JamiPluginsCertification: add description of certificate process
Gitlab: #19 Change-Id: I3fb2a45f47f64bb89b1b33bdc72226e757f4b02b
This commit is contained in:
Xavier Jouslin de Noray
Sébastien Blin
parent
7a3d3ca052
commit
58e86a922a
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
|
|
@ -0,0 +1,81 @@
|
|||
**NOTE: this page describe the architecture of the certificate for Jami plugins store**
|
||||
|
||||
# Jami plugins certificate
|
||||
|
||||
Jami team has introduced plugins as a call/chat feature for GNU/Linux, Windows and Android, providing users the ability to personalize your call/chat experience. If you want to learn more about Jami plugins check [Jami Plugins Page](./jami-plugins.md).<br/>
|
||||
Jami's team decided to include a Jami plugin store to be able to distribute the Jami's team plugins and third-parties plugins.<br/>
|
||||
To ensure trust in Jami's team and third-parties plugins, a certificate mechanism is required. Certificates play a crucial role in verifying the authenticity of the plugins available in the Jami plugin store.<br/>
|
||||
By leveraging certificates, users can have confidence in the origin and integrity of the plugins they choose to install.<br/>
|
||||
|
||||
## Certificate
|
||||
|
||||
Within the Jami plugin architecture, three types of certificates are available: Store Root C.A., Organization Certificate and Plugins Certificate. The Jami Client has the responsibility to verify the certificate chain and enforcing the constraints established by this document.<br/>
|
||||
An organization is a third party. It has the right to add plugins in the plugins store.
|
||||
Certificate within the system, except for the plugin certificate, can sign a certificate or a plugin with the Elliptic-curve cryptography(ECC) algorithm.<br/>
|
||||
Jami team chose ECC algorithm instead of RSA algorithm due to its strong cryptographic properties with shorter key lengths, making it well-suited for resource-constrained devices like mobile phones.<br/>
|
||||
Certificates are based on the X.509 standard. Certificate contains essential information such as: issuer information, subject information, signature and validity period, revocation rules and some none essential information.<br/>
|
||||
It's recommended to set the validity period to 1 year.<br/>
|
||||
Each Issuer and Subject have a common name, a private key, a dynamic public key and some information about the owner or plugin of the certificate.<br/>
|
||||
Every file and archive is signed by a plugin certificate. The certificate is able to validate the entire chain of certificate leading back the root certificate([learn more about signature mechanism](#signature-mechanism)).<br/>
|
||||
The certificate lifecycle management is designed in the Opendht library.<br/>
|
||||
The certification revocation is also managed by the Opendht library. If you want to know more about the Opendht library check [OpenDHT Page](https://opendht.net).<br/>
|
||||
|
||||
## Signature mechanism
|
||||
|
||||
A signature is a hash generate by a subject certificate private key. This signature can be verified with the public key of the subject. As an organization, a certificate has to be signed by the root certificate<br/>
|
||||
After to be granted by the root certificate, an organization can sign plugins certificate. This plugins certificate is able to sign a file of the plugin.<br/>
|
||||
When a plugin is publish, the plugin certificate must sign all the files.
|
||||
The plugin archive(plugin.jpl) must contain the manifest(manifest.json), the library directory(lib), the data directory(data) the plugin certificate(<plugin_name>.crt) and the signature file(signatures) and the signature file(signatures.sig).<br/>
|
||||
```bash
|
||||
├── <plugin_name>.jpl
|
||||
│ ├── data
|
||||
│ │ ├── **/*.*
|
||||
│ ├── lib
|
||||
│ │ ├── x64-windows
|
||||
│ │ │ ├── *.dll
|
||||
│ │ │ ├── *.lib
|
||||
│ │ ├── x86_64-linux-gnu
|
||||
│ │ ├── *.so
|
||||
│ ├── manifest.json
|
||||
│ ├── <plugin_name>.crt
|
||||
│ ├── signatures
|
||||
│ ├── signatures.sig
|
||||
```
|
||||
<br/>
|
||||
The manifest.json contains all information about the plugin.<br/>
|
||||
The library directory contains all the dependencies to build the plugin.<br/>
|
||||
The data directory contains all data needed for the plugins(image, model, ...).<br/>
|
||||
The plugin certificate is the certificate format with x.509 standard.<br/>
|
||||
The signature file contains a Map include file name as key and signature hash as values(<file_name> <signature_hash>).<br/>
|
||||
The signature file contain the signature of the signatures file<br/>
|
||||
|
||||
## Certificate Chain
|
||||
|
||||
The Store Root C.A. is the certificate authority. This certificate has the responsibility to sign the Organization Certificate. The Organization Certificate is the certificate of the organization.<br/>
|
||||
This certificate has the responsibility to sign the Plugins Certificate. The Plugins Certificate is the certificate of the plugin. This certificate has the responsibility to sign the plugin.<br/>
|
||||
|
||||
<br/>
|
||||
|
||||
In this example, the certificate authority trust SFL and Foo organizations. SFL organization trusts there Plugin certificate representation(Green Screen and Whisper).<br/>
|
||||
Foo organization trust there Plugin certificate representation(Bar). The plugin certificate representation sign the different version of the plugin.<br/>
|
||||
|
||||
## Certificate Constraint
|
||||
|
||||
Store Root C.A. certificate can sign only Organization Certificates.<br/>
|
||||
A Organization Certificate can sign only Plugin Certificates.<br/>
|
||||
A Plugins Certificate can sign only Plugin files. The certificate chain must be respected. The certificate chain is the following: Store Root C.A. -> Organization Certificate -> Plugins Certificate -> Plugin Files.<br/>
|
||||
|
||||
### Certificate Revocation
|
||||
|
||||
The certificate revocation mechanism allows a certificate signed by a certificate authority to be revoked.<br/>
|
||||
In fact, the root certificate can revoke an organization certificate and a plugin certificate. An organization certificate can revoke its own plugin certificate.<br/>
|
||||
OpenDHT uses the Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) to verify the status of the certificate. The daemon checks the CRL for every certificate authority. After this check, the daemon sends a request to the OCSP server to check the status of the certificate chain own by the plugin.<br/>
|
||||
The OCSP server endpoint is stored in the certificate. If the server response indicates that all the certificates in the signature are not revoked and not unknown, the client is allowed to add the plugin to its list.<br/>
|
||||
For instance, Bob wants to add the Green Screen plugin to his list of plugins. Bob interacts with the front end that triggers an event to pull all files related to the Green Screen plugin.<br/>
|
||||
The steps to validate the signature of files are:
|
||||
1. the daemon checks the signature of each file<br/>
|
||||
2. verifies that the name of the plugin matches the name in the manifest (each manifest must have a name property)<br/>
|
||||
3. checks the certificate chain.<br/>
|
||||
4. the daemon requests the status of the certificate chain by requesting the OCSP server (Green Screen plugin certificate, SFL certificate, and Store Root C.A.).<br/>
|
||||
5. If the certificate chain is verified and trusted, the plugin can be installed.<br/>
|
||||
6. If one of the certificates that compose the certificate chain is revoked, all the files of the Green Screen plugin are removed<br/>
|
||||
Loading…
Reference in New Issue