#Device Certificate Manager

##About

The Device Certificate Manager (DCM) provides cryptography services (digital certificates and keys) for authentication and secure communication with another system.
Please visit the following webpage for the details about the prerequsities and the usage: [https://docs.tizen.org/application/native/guides/security/device-certificate-manager](https://docs.tizen.org/application/native/guides/security/device-certificate-manager).

##Architecture

The DCM (tizen.org repository *platform/core/security/device-certificate-manager*) consists of two submodules: the client and the daemon.
The client provides the public DCM API, while the daemon its implementation.
The implementation is realized with the internal backend API (see the *dcm-daemon/dcm-backend-api.h* header file).
Example implementations of this backend API may be found in the tizen.org separate repository: *platform/core/security/device-certificate-manager-backend*.
The DCM backend repository provides two implementations:
1) dedicated for the KONAI SE device,
2) based on the OpenSSL and dedicated mainly for the testing purposes.
Both of them are packed to the separate rpm packages (respectively with the *kse* or the *dummy* in names), that provide the *libdcm-backend-api.so* library with the DCM backend API implementation.
The library is loaded dynamically by the DCM daemon at runtime.
Although the DCM backend is not installed automatically with the DCM, it is required for proper work of the DCM and because of that it must be installed manually.
Alternatively, the specific Tizen image may be configured to contain the chosen backend.

###The KONAI SE backend

The KONAI SE backend uses the *libkonaise.so* closed library in its implementation.
In order to use this backend, the KONAI SE library must be installed in the system (and the KONAI SE must be connected to the device).

###The OpenSSL backend

The OpenSSL backend uses the open source OpenSSL library.
The OpenSSL certificate chain is ordered inversely, compared to the SE certificate chain, therefore, the order of the chain must be reversed within the implementation.
The difference in the cerificates ordering is the reason why the *backend* level of abstraction is needed (instead of using the SE libraries with the common API directly in the DCM daemon).

##Adding a new backend (a new SE device)

In order to support a new SE device in the DCM, a new backend API implementation must be developed, which means that the plugin developer must provide the  implemenation of the plugin header (*dcm-daemon/dcm-backend-api.h*).
Such an implementation may be based on the KONAI SE implementation from the *platform/core/security/device-certificate-manager-backend* repository.
The new implementation may be added to this public repository or provided in the separate git repository.
The most important item is to implement the *libdcm-backend-api.so* library and to install it in the system.
The DCM daemon does not need to be modified.

##Testing

There are currently four general testing applications and one KONAI SE specific tool:
- *dcm_api_test*
- *dcm_example_capi*
- *dcm_example_client*
- *dcm_test_cert_rewriter*
All testing applications should be executed after implementing changes to the DCM or to the DCM backend repository.

There is also one KONAI SE specific tool: *dcm_konaise_tool* used to test the KONAI SE backend implementation.
The list of examples of execution of the *dcm_konaise_tool* is displayed after running the tool in the command line without any arguments.