Security/Tizen 3.X Key Manager

From Tizen Wiki
Jump to: navigation, search

Project News

Latest release: 0.1.14


Key manager provides a secure repository for keys, certificates, and sensitive data related to users and their password-protected APPs. Additionally, it provides secure cryptographic operations for non-exportable keys without revealing key values to clients. Key manager stores all user's data in a central secure repository protected with user's password.

Project Goals

  • What is the project? Tizen middleware as well as applications often need to protect their content by encrypting it, or ensure identity verification with asymmetric cryptography. They also need to store their secret data like private keys in a safe place. Key-manager provides methods for all these cryptographic operations without disclosure of the key itself as well as a safe storage for sensitive data.
  • What is provided by the project?
    • RSA, DSA, ECDSA and AES key management.
    • Certificate management.
    • Encryption/decryption support (Several AES modes, RSA).
    • Signing/verification (RSA, DSA, ECDSA).
    • Certificate chain verification and OCSP check.
    • Sharing sensitive data between applications.

Project History

  • Project was started in 2014 by Dongsun Lee (
  • The project is an alternative to key-rings and partially covers secure-storage functionality.
  • Comparison with existing projects
    • Key-rings - offer safe key storage but do not provide a possibility of performing cryptography operations without key disclosure.
    • Openssl - provides complicated cryptography API. Key manager covers openssl with easy to use C/C++ API and but is able to use different cryptographic library as well (also simultaneously).
  • Current release is 0.1.14 and is available with latest common Tizen image.
  • Comparision with Tizen 2.X
    • Applications are identified with pkg_id + app_id instead of smack labels. Therefore we'll have to ask security-manager to translate the process label to pkg_id and app_id. More details...
    • is a multiuser environment. Currently there's one common key-manager service for all users. Key-manager supports database per user.
      • Key-manager-listener should consider user id when removing application data.
      • User removal should result in database removal. This is implemented by integrating key-manager with gumd.
    • has a different logging manager. Instead of security-server key-manager is integrated with PAM.
    • 3-domain policy. In Tizen 2.X the access to key-manager services was controlled by smack (socket labelling). In the service itself is responsible for access control check using Cynara.

Contact information


  • Secure storage for keys (RSA, DSA, ECDSA, AES), certificates and sensitive data.
  • Sharing stored objects between applications.
  • Key generation (RSA, DSA, ECDSA, AES).
  • Signing and signature verification without key disclosure.
  • Certificate chain verification.
  • OCSP (Online Certificate Status Protocol).
  • Data encryption and decryption with a key stored in key-manager without key disclosure. More details...
  • Initial value setting allowing predefined data to be stored in key-manager database during first execution. More details...
  • User session support. Protects user's database with his password and unlocks/locks it on login/logout. More details...
  • Trusted Execution Environment support.

Tizen Context

Web app encryption

During image creation cryptographic keys are stored in a predefined location and are used to populate the database on first launch. These keys will be used at runtime to decrypt web application data. Keys are removed from the filesystem after being imported. More details...

Secure key ring

Key manager works as a secure key ring with a possibility to sign & verify messages without disclosing the key. Applications and users can store their keys separately and can additionally protect them with passwords. Keys can be used for implementing secure communication channel or sensitive data encryption.

Certificate verification

Key manager can be used to verify a chain of trust for given certificate and performing OCSP (for example during verification of application signatures). Each user and application can have a different set of trusted certificates and use them for certificate verification.

Non functional requirements

  • MDPP compliance.
  • Ability to process time-consuming requests simultaneously.
  • Asynchronous interface for binding Javascript functions.

Implanted standards

  • W3C Cryptography API - Key manager should provide an interface that can be easily bound to Javascript functions.
  • RSA, DSA, ECDSA, AES - keys and cryptographic operations suppport.
  • OCSP support.
  • X509 - support for certificate format and certificate verification procedure.
  • Pkcs12 - possibility to import data from Pkcs12 file.

API overview

Project packages

  • Required:
    • key-manager - package containing server binary.
    • libkey-manager-client - client library.
    • libkey-manager-common - common library shared by client and server.
    • key-manager-pam-plugin - plugin for integration with user session.
    • key-manager-listener - listener daemon notifying the service about app deinstallation.
  • Optional:
    • key-manager-tests - internal/unit tests.
    • development package.
    • debug packages.

Key manager most important dependencies include:

  • openssl - for cryptographic operations and structures.
  • smack - for process identification
  • journald - for logging

Running the project

  • Important files:
    • /usr/bin/key-manager - key-manager server binary
    • /usr/lib/systemd/system/*/central-key-manager* - server sockets and systemd configuration
    • /usr/share/ckm/scripts/* - database initialization and migration scripts
    • /usr/lib/libkey-manager*.so - client libraries and internal libraries
    • /usr/bin/key-manager-listener - key-manager-listener binary
    • /usr/lib/security/ - pam plugin
  • Installation:
    • Zypper: zypper in key-manager key-manager-listener key-manager-pam-plugin
    • Rpm (assuming packages are in current directory): rpm -Uvh *key-manager*.rpm
  • Configuration
    • Logs for client and server can be configured in /etc/sysconfig/central-key-manager with two variables: CKM_LOG_LEVEL and CKM_LOG_PROVIDER. Server has to be restarted after file modification. CKM_LOG_LEVEL is responsible for setting logs sensitivity (0-None, 5-All). CKM_LOG_PROVIDER is used to select logging subsystem. Available options are:
      • CONSOLE
      • DLOG
      • JOURNALD (default)


  • Initial values. Files in /opt/data/ckm/initial_values/ directory will be imported to key-manager database upon server startup and removed from file system. Files have to be compatible with /usr/share/ckm/initial_values.xsd schema. More details...
  • Databases. User databases and data encryption keys are stored in /opt/data/ckm/.
  • Starting/Restarting/Closing the services: systemctl start/stop/restart central-key-manager/central-key-manager-listener

High Level Architecture

  • List of processes:
    • key-manager (systemd service)
    • key-manager-listener (systemd service)
    • client process
  • List of databases:
    • There's one database per user: /opt/data/ckm/db-<uid>, and one system database for system users (uid < 5000) /opt/data/ckm/db-0. Databases are created during first access. Initially there are no databases.
  • HLA diagram


  • Repos
  • Branches
    • Key-manager uses branch tizen for development. Release versions are marked with tags.
    • Security-tests uses branch ckm for development. tizen branch is treated as a release branch.
  • Maintainers
    • Bartłomiej Grzelewski (
    • Krzysztof Jackiewicz (
    • Maciej Karpiuk (
  • Code style:
    • Adjust to existing code style
    • Wrap lines at 100 characters
  • Debugging. You can attach to server process with gdb. Run systemctl status central-key-manager to obtain server process pid. Attach with gdb -p <pid> Client can be debugged by running it with gdb.
  • Input/Output data format:
    • Data used in API for asymmetric keys and certificates creation can be both in PEM and DER format.
    • Pkcs API supports PKCS #12 file format.
    • Initial values format is defined here.
  • Testing. There are 2 types of tests for key-manager:
    • Internal unit-like tests. Compiled as a part of the project. Based on boost test framework. Tests are packaged in key-manager-tests rpm. After installation run: ckm-tests-internal
    • External system-like tests. Compiled in a separate security-tests repository. Most recent (development) version of tests can be found on ckm branch. Tizen branch contains tests compatible with latest release version of key-manager. After installation run: ckm-tests --output=text
  • Release strategy (version numbering). Software release is performed with gbs-submit command. Security-test are 'released' by merging ckm branch to tizen branch with each key-manager release so that tizen branch always contains tests compatible latest release of key-manager. Key-manager version is in form X.Y.Z. 'Z' number is increased with each minor release. In case of releases that introduce API modification the 'Y' number is incremented.
  • HOWTO get involved:
    • Code review
    • Bug reporting -> contact maintainers
    • Bug fixing -> prepare fix + test + contact maintainers
    • Feature requests -> contact maintainers

See also