Security:cert-checker

From Tizen Wiki
Jump to: navigation, search

Cert-Checker

Introduction

Project Goals

Cert-checker is a daemon, which checks OCSP of every new installed application. It doesn't provide any new external API.

Cert-checker checks for package-manager and connman DBus signals, and when:

  • package-manager signal "new application installed" is received it adds the application to "to check list",
  • package-manager signal "application removed" is received cert-checker removes it from "to check list",
  • connman - status: online signal - cert-checker checks OCSP for all application from "to check list".

If OCSP status is OK, then nothing happens (application stays in the system). If OCSP returns revoked status then user must decide (via popup) whether uninstall application or keep it in the system.

Project History

  • Project has been started in Q1 2015 by Dongsun Lee (ds73.lee@samsung.com)
  • Project hasn't been released yet.

Contact information

Features

Project doesn't provide any API. It's a "passive" daemon which do some action based on DBus broadcast signals.

Needs

  • The leaking of a key from a certain weak CA will put Tizen Eco system in danger.
  • To protect Tizen Eco system from these vulnerabilities, applications signed by revoked certificates must not be installed on devices.
  • Certificate status check with OCSP during installation process will be an appropriate solution.

Proposed solution

  • To enhance security during application installation, the additional OCSP verification step should be added
  • However, we should temporarily allow the installation of application when the network connection is unavailable.
If not, it will make a lot of troubles and complaints such as application testing at the factory
  • These temporarily installed applications should be checked again when the network connection is available.
If some certificates of installed application were revoked, these applications can be disabled.
  • Each CA should provide an OCSP service and manage its certificates’ revocation status

Requirements

  • Each downloaded application is checked for the cert status just once.
- Even if a cert of an already installed application is revoked, the app should not be disabled as long as the cert was already verified during its installation time.
  • To disable an app with a revoked cert, the approval from a user is required.
  • Issuer’s OCSP URLs specified in latest child certificates are used for OCSP checking.
- cert-checker has OCSP URLs of an each issuer for the all signing certificates.
- The issuer’s OCSP URLs are extracted from the child certificates issued by the issuer.
- If a newly issued child certificate has a new OCSP URL, the issuer’s OCSP URL stored in cert-checker will be updated.
- If an issuer’s OCSP URL is not specified, then the OCSP status of the cert is regarded as valid. This is for the situation where the current Tizen certificates doesn’t have the OCSP URL.

Tizen Context

OCSP should be checked by package installer, but in case when there's no the Internet connection, the installer will just skip checking OCSP and let to install package/application. Cert-checker waits for information about package installation (via DBus) and perform OCSP check for all new installed application when Internet connetion appears.

API overview

No external API

Project packages

RPMs packages:

  • cert-checker - pacakge with binary, database, and systemd configuration.
  • cert-checker-tests - unit test for cert-checker.

Dependency:

  • cert-svc-vcore - searching and parsign application signatures, building certificates' chains,
  • key-manager - checking OCSP,
  • glib, dbus - listening fot DBus signals,
  • sqlite3, db-util - database support,
  • libsystemd-journal - logs,
  • notification - popup,
  • libtzplatform-config - system paths (database, applications),
  • boost-devel, boost-tests - tests

Running the project

Important files:

  • /usr/bin/cert-checker
- binary
  • /usr/dbspace/.cert-checker.db
- database
  • /usr/lib/systemd/system/cert-checker.service
  • /usr/lib/systemd/system/multi-user.target.wants/cert-checker.service
- systemd configuration

Starting/Restarting/Closing/Status the cert-checker service:

systemctl start cert-checker
systemctl restart cert-checker
systemctl stop cert-checker
systemctl status cert-checker

Logs:

  • journalctl -f | grep cert-checker
  • By default cert-checker is build with only error logs. To turn on debug logs rebuild package with gbs build flag:
--define "build_type DEBUG"

High Level Architecture

Needed Frameworks

  • Notification framework (service used via library synchronous API). Since notification framework is corrupted, temporary internal implementation of popup will be used.
  • Pkg-manager
    • Service - Notification via Dbus. Used interfaces:
      • org.tizen.slp.pkgmgr_status, /org/tizen/slp/pkgmgr/install, org.tizen.slp.pkgmgr.install
      • org.tizen.slp.pkgmgr_status, /org/tizen/slp/pkgmgr/uninstall, org.tizen.slp.pkgmgr.uninstall
    • Library - Synchronous API for deactivate the app
  • Connman (notification via Dbus). Used interface:
    • net.connman, /, net.connman.Manager
  • Cert-svc (library for OCSP)
  • Framework for getting certificate from signature.

Pkg-manager and connman notifications should work in one gmain loop. No additional thread will be needed - notification service will be responsible for displaying popups.

List of certificates to check

  • Database is needed to store certificate/applications to check after reboot.
  • For each application all certificates from its signature will be kept in database (for building chain).
  • The unchecked certificates will be loaded from database to a buffer on daemon start.
  • On notification from pkg-manager about app installation (or update) certificate will be added to the database and to the buffer.
  • On notification from pkg-manager about app uninstallation certificate will be removed from the database and from the buffer (if present).
  • If OCSP returns OK (or certificate unknown), certificate will be removed from the database and the buffer.
  • If OCSP returns network error (or timeout), certificate won't be removed from list (will be checked later again).
  • If OCSP result is Revoked, then cert-checker should:
    • Display popup window with information/question to user:
      • If user wants to disable/uninstall application, cert-checker will do it via pkg-manager API.
      • If user doesn't want to disable/uninstall application, certificate will be removed from the database and the buffer.
  • Cert-svc API will be used to build the certificate chain (search and parse signatures, build certificates' chains).
  • Key-manager API will be used to verify the OCSP.
  • If OCSP will fail (returns anything but OK or certificate unknown) for any of certificate in chain - this means OCSP have failed.

OCSP logic

  • Checking OCSP. To verify OCSP all certificates in chain must be checked (exclude certificates without OCSP URL). All certificate must return "OK" to pass OCSP (to be "valid"). If any of certificate returns "Revoked", whole chain and the application will be considered as "Invalid".
  • Application can contain more than one signature - if at least one certificate in any signature is revoked the whole certificate is considered to be "Invalid".
  • If an network (or similar, no recurrent) error occurs while checking OCSP, then application should be skipped and checked again later.
  • If any recurrent error occurs (broken certificate chain, broken certificate, etc.), then certificate chain is considered to be "valid". However this should never happen, because installer should not install application with incorrect certificate chain.

OCSP URL logic

  • In url database for OCSP we keep only one url for every issuer.
    • If we have two different urls for same issuer we choose the one from certificate which have been issued later.
  • If certificate have OCSP url then this url should be used.
  • If certificate doesn't have OCSP url then we should use url from database for the same issuer.
  • If certificate doesn't have OCSP url and there is no url in database - do not check OCSP.

Daemon activation

Daemon will be run or woken up by Dbus with notification from:

  • Pkg-manager
    • Activation by pkg-manager causes adding app’s certificate to the database and the buffer
  • Connman
    • Activation by connman causes check the buffer if there are any certs to check – and check them if needed.

Launching the daemon can be delayed in time to avoid slow-down while system start.

User Popup question/info

To display user popup Notification service will be used

  • This is synchronous API (library)
  • Localization support (dgettext)

Multi user

Cert-checker should support multi user. This require that pkg-mgn and notification framework also have to support multi user.

  • Cert-checker should get information about user (app-owner) from pkg-mgr while app installation.
  • Notification framework should provide API to display pop-up to certain user, and should return an error if user isn't logged in.

Components diagram

Cert-checker componets diagram.png

Doubts and questions

  • Question: Where keep URLs for OCSP? The best solution is to keep URL database in OCSP engine (cert-svc) - in this way installer and cert-checker will use the same OCSP mechanism (will get the same results and won't duplicate the code).
- Answer: OCSP URLs are kept in internal cert-checker database. So OCSP API that supports custom URLs is needed.
  • Question: How to get certificate from the signature?
- Answer: Cert-svc API supports searching signatures, and can parse them to get certificates.

Detailed Design

  • Leading a user to remove identifed malicious applications

The UI of setting application for application management can be launched by the following AppControl sample code.

 app_control_h service = NULL;
 int result = 0; 
 result = app_control_create(&service);
 if(result != APP_CONTROL_ERROR_NONE) {
     return;
 }    
 ret_if(NULL == service);
 app_control_set_operation(service, APP_CONTROL_OPERATION_DEFAULT);
 app_control_set_app_id(service, "setting-manage-applications-efl");
 app_control_add_extra_data(service, "viewtype", "application-info");
 app_control_add_extra_data(service, "pkgname", "pkg_name_to_delete");
 app_control_send_launch_request(service, NULL, NULL);
 app_control_destroy(service);

The bold characters should be changed into the package name to delete.

State diagram

Cert-checker states diagram.png

Notes - OCSP logic::

  • Checking OCSP. To verify OCSP all certificates in chain must be checked (exclude certificates without OCSP URL). All certificate must return "OK" to pass OCSP (to be "valid"). If any of certificate returns "Revoked", whole chain will be considered as "Invalid".
  • Application can contain more than one signature - if at least one certificate in any signature is revoked the whole certificate is considered to be "Invalid".
  • If an network (or similar, no recurrent) error occurs while checking OCSP, then application should be skipped and checked again later.
  • If any recurrent error occurs (broken certificate chain, broken certificate, etc.), then certificate chain is considered to be "valid". However this should never happen, because installer should not install application with incorrect certificate chain.

Class diagram

Cert-checker class diagram.png

Database

Database will use PRAGMA user_version to keep version of database's schema (starts from "1"), to make schema update possible.

Cert-checker database diagram.png

Tests

To test cert-checker install cert-checker-tests rpm package, and run:

cert-checker-tests; cert-checker-tests-logic

All tests should pass.

To test UI (popup) run

cert-checker-popup-test.

The popup should appear. Try to push some buttons, and check the logs to see if popup works correctly:

journalctl -f | grep cert-checker

Future release plan with dates (includes functionalities planned for a release)