Security/Tizen 2.X cert-svc

From Tizen Wiki
Jump to: navigation, search

Cert-svc provides various certificate related functions to manage user and system certificates and to support application's certificate related functions such as verifying application signing and the privilege level of application. The following picture indicates representative applications which use cert-svc.


Cert-svc.png


Contents

Managing Certificate

Most certificates follow X.509 standard. The well-known opensource project, OpenSSL, provides various APIs to manage X.509 standard certificates. In cert-svc, new convenient APIs based on OpenSSL are provided.

function group description
Store Certificate Copy the certificate that user wants to use to designated location.

Copied certificate will not be overlapped and only CA certificate will be allowed to copy.

Delete Certificate Delete certificate which be useless. In order to delete some certificate, the application must have related permission.
Extract Certificate Parse a certificate and store into predefined data structure.

We can only extract the certificate which is abiding by X.509 standard.

Search Certificate Search specific certificate which is matched with user inputted file name and content and return the location of that certificate.

The return value will be NULL(if not exist) or one or more locations of certificate.

Verify Certificate Verify the validity of that certificate using the certificate(s) that are inputted by user.

The root CA certificate must be in certificate store, and if needed, user should input the intermediate CA certificate(s).

Verify Signature Verify the validity of that signature using the message, the signature of that message, and the certificate that are inputted by user.














Additional certificate service APIs

Cert-svc-vcore provides the additional extended service of cert-svc as below.


(1) Application install support

To verify application signing and get privilege level of application, the cert-svc-vcore provides additional functions.

  • The cert-svc-vcore offers certificate related functions and its proper data structure for checking application signing. [more detailed signing verification processes]
    • All applications should be signed by developer or trusted organization to be assured their integrity.
    • To verify application signing, the cert-svc-vcore provides ValidationCore APIs.
      • Among ValidationCore APIs, the osp-installer uses ValidationCore::SignatureValidator APIs to verify tpk application signing.
      • Also, ValidationCore::WrtSignatureValidator APIs are used by wrt-installer to verify web application signing.
    • The application signing scheme fully follows the W3C specification for widget signing (http://www.w3.org/TR/widgets-digsig/).
App signature example.png
  • To allocate exact authority for application, the cert-svc-vcore provides extract privilege level function from an application's certificate.
    • Application’s privilege and permission to use of authorized API set can be verified by different signing keys
      • Public : signs normal 3rd party applications which use use only public level API
      • Partner : signs applications which use partner level API
      • Platform : signs applications which use platform level APIs
    • Scope of API coverage
      • Public < Partner < Platform
Tizen 2.x Get privilege.png

(2) OCSP support

Cert-svc-vcore provides additional OCSP related functions. Vcore OCSP functions are independent of OpenSSL OCSP APIs.

[Ocsp]

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate.
It is described in RFC 6960 and is on the Internet standards track.

(3) CRL support

Cert-svc-vcore supports CRL related functions to check the revocation status of certificates.

[CRL]

a certificate revocation list (CRL) is a list of certificates (or more specifically, a list of serial numbers for certificates) 
that have been revoked, and therefore, entities presenting those (revoked) certificates should no longer be trusted.

(4) PKCS12 support

Because cert-svc provides limited PKCS12 related functions, the cert-svc-vcore provides expanded PKCS12 functions.

[PKCS]

In cryptography, PKCS #12 defines an archive file format for storing many cryptography objects as a single file. 
It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust.

Main API

Store and Delete Certificate



API Name cert_svc_add_certificate_to_store

  • Description : extract a certificate using filePath and save a certificate into designated location
  • Input Parameter :
Name Description
const char* filePath the file path of the certificate
const char* location the location to be stored
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail


API Name cert_svc_delete_certificate_from_store

  • Description : get the name of certificate which user wants and delete that file.
  • Input Parameter :
Name Description
const char* filePath the name of certificate to be deleted
const char* location the location of certificate
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail




Context Management



API Name cert_svc_cert_context_init

  • Description : allocate a memory for CERT_CONTEXT structure and return its address. If user wants to use context, this function should be called.
  • Return :
Return Type : CERT_CONTEXT*


API Name cert_svc_cert_context_final

  • Description : free a memory buffer of Context. After allocating memory of Context, this function should be called in order to prevent memory leak.
  • Input Parameter :
Name Description
CERT_CONTEXT* ctx The pointer of context which will be freed
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail




Load Certificate



API Name cert_svc_load_buf_to_context

  • Description : Load the buf content into certBuf field of ctx. The content of memory buffer should be PEM-formatted certificate.
  • Input Parameter :
Name Description
CERT_CONTEXT* ctx the context of certificate
unsigned char* buf the memory buffer of certificate
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail


API Name cert_svc_load_file_to_context

  • Description : Load the content of filePath file into certBuf field of ctx. Our module supports PEM(*.PEM / *.pem), DER(*.DER / *.der), CRT(*.CRT / *.crt), CER(*.CER / *.cer) format.
  • Input Parameter :
Name Description
CERT_CONTEXT* ctx the context of certificate
const char* filePath the file path of certificate
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail


API Name cert_svc_load_PFX_file_to_context

  • Description : The PFX-formatted certificate is made by PKCS#12 standard and Its file format is pfx or p12. Unlike another certificates, The PFX file includes public key certificate and private key. This API can get the PFX-formatted certificate of user, load certificate into certBuf field of ctx, and load intermediate CA certificates into certLink field of ctx (if exists).
  • Parameter :
Name Description
CERT_CONTEXT* ctx the context of certificate
const char* filePath the file path of certificate
char* passPhrase the passphrase of pfx certificate
(output) unsigned char** privateKey the privete key in pfx certificate
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail


Process Certificate



API Name cert_svc_verify_certificate

  • Description : Verify the validity of certificate in ctx. After finishing function, if validity is 1, the certificate is valid, if validity is 0, not valid. And the file path of root CA certificate is stored in fileNames field of ctx.
  • Input Parameter :
Name Description
CERT_CONTEXT* ctx the context of certificate
int* validity the result of verification
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail

API Name cert_svc_verify_signature

  • Description : Verify the validity of some signature. The certificate which be needed must be stored in certBuf field of ctx. We should know the hash algorithm because this API calculates hash value of the original message and decrypts the signature, and compares those two values. Therefore user should input hash algorithm and if hash algorithm is NULL, the hash algorithm in certificate will be used. After finishing function, if validity is 1, the signature is valid and if validity is 0, the signature is not valid.
  • Algorithm : The hash algorithm indicates which algorithm will be used to make signature. In this module, the following algorithms are provided: md4, md5, sha, sha1, sha224, sha256, sha384, sha512, ripemd160.
  • Parameter :
Name Description
CERT_CONTEXT* ctx the context of certificate
unsigned char* message the original message
int msgLen the length of original message
unsigned char* signature the signature of message
char* algo the hash algorithm of signature
(output) int* validity the result of verification
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail

API Name cert_svc_search_certificate

  • Description : free a memory buffer of Context. After allocating memory of Context, this function should be called in order to prevent memory leak.
  • Input Parameter :
Name Description
CERT_CONTEXT* ctx The context of certificate
search_field fldName The field name will be used to search
char* fldData The data will be used to search
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail




Check certificate status



API Name cert_svc_check_ocsp_status

  • Description : In order to check revocation status of inputed certificate, we use the OCSP. The server address of OCSP is determined in order of as follows: (1) The address which be written in AIA field of inputed certificate will be used, (2) If there is no AIA field in certificate, the parameter uri will be used
Name Description
CERT_CONTEXT* ctx The context of certificate
const char* uri OCSP server address
  • Return :
Return Type : INT
If 0, Success
If < 0, Fail




Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox