Data & files encryption and digital signature services

The data & files refer to non-PDF format files and data. Because PDF format files have digital signature and encryption standards, we must implement digital signatures and encryption in accordance with their standards. And for other format files, such as text files, picture files, audio files, video files, office files, CAD files, etc., there are about three hundred kinds, of course, including string data. Most of these files do not support digital signature and encryption. Fortunately, these files can be classified into MIME types.

MIME (Multipurpose Internet Mail Extensions) was originally designed to allow emails that only support text to support all kinds of format of files to be sent as email attachments. After the emergence of the http protocol, in order to allow HTML to support all file formats, the MIME framework was also adopted, making MIME an Internet media type used to represent the format of files or data streams. The HTTP transmission protocol, because of the insecure cleartext transmission, has the HTTPS protocol that is now widely used. This protocol supports the use of SSL certificate to achieve encrypted transmission. Similarly, because MIME cleartext email is not secure, there is the S/MIME protocol (Secure/Multipurpose Internet Mail Extension), which supports the use of email certificate to implement email encryption and digital signature. The "S" of the two protocols is the first letter of "Secure".

In other words, with the S/MIME standard, the digital signature and encryption of all kinds of files can be realized, and the S/MIME standard can be used to package all format files into a digital envelope to protect all data and files to make sure the identity is trusted and encrypted for storage. MeSign Technology is very familiar with S/MIME email encryption and digital signature technology. It has realized the automatic encryption and digital signature of emails, and has also innovatively added email timestamp applications based on the S/MIME standard. This is the technical basis for MeSign Technology to implement digital signature, encryption and time stamp services for all kind of files and data.

MeSign Technology uses S/MIME standard and digital envelope technology to help application software and Internet services realize the digital signature of data and files in two ways: SDK and API, so as to ensure the trusted identities of these data and files; to realize the certificate encryption of all data and files in all formats to ensure the security of the confidential information of these data and files; to realize the time stamping of all data and files in all formats to ensure that the time when these data and files are generated and used is trusted and non-repudiation; to realize the location stamping of all data and files in all formats to ensure that the location information when these data and files are generated and used is trusted and non-repudiation.

1. Data & files encryption service

To achieve data & files encryption, there must be an encrypting certificate. According to the S/MIME standard, of course, the encrypting certificate must be bound to an email address, that is, each user (data producer or data user) must have an email address and must have an encrypting certificate bound to this email address. If you need to encrypt data, you also need the public key of the user who has the right to decrypt the data, this is the same as the implementation of email encryption. MeSign Cryptography as a Service can help users easily implement certificate encryption for all format files and data, there are two service modes: cloud encryption mode and local encryption mode. Users can choose different encryption service modes according to their business needs.

1.1 Cloud encryption mode

In order to protect the security of the encrypting key, the encrypting key is not stored on the user's device, it is generated and stored securely in the cloud key management system (KMK). As show in the figure below, if user A wants to send secret data to user B, then A generates the symmetric key of the data and posts it MeSign Data Encryption Service system via https to request encryption. The Encryption Service system encrypts the symmetric key with user B’s public key and returns it to user A, then user A can use the encrypted symmetric key with a digital envelope format to encrypt the secret data, and send the encrypted data to user B. After receiving the encrypted data, user B extracts the encrypted symmetric key and posts it to the MeSign Data Encryption Service system for decryption via https. The Encryption Service system decrypts it with user B’s private key and returns the decrypted symmetric key to User B, then user B can decrypt the secret data in the digital envelope.

This encryption mode solves the security problem of the encrypting key on end point. The cloud cryptography service performs encryption and decryption services on behalf of the end point without exposing important encrypting keys to insecure end points. Of course, there must be a corresponding identity authentication service that must validate user’s identity for decryption request. Please also refer to the blog post "Interpretation of the RSA master’s PPT - "Cryptography as a Service".

1.2 Local encryption mode

The local encryption mode is to retrieve the encrypting key and encryption certificate from cloud KM to the user's local device and store it securely in the SDK, as shown in the figure below. Each user must have an encrypting certificate (including encryption key). The user submits a request to obtain an encrypting certificate through the SDK. The certificate is bound to the user email address. After the email control validation is done, the encrypting certificate is issued and downloaded to the SDK key store, used to decrypt encrypted files. The application and configuration of encrypting certificates for users only needs to be automatically completed by the SDK when the encryption service is used for the first time.

The business system posts the email address of the data recipient to the SDK, and the SDK obtains the user's encryption public key, and the SDK is responsible for encrypting the data or file with this public key to realize the certificate encryption of the data or file. The decryption process is to post the encrypted data or file to the SDK. The SDK calls the private key to decrypt the data or file. The decrypted cleartext file is given to the user in the format before the encryption, and the user can use the decrypted data or file.

This encryption mode greatly improves the encryption efficiency. After obtaining the user's encrypting private key and the other party's encrypting public key, it no longer depends on the cloud data encryption service system. Data encryption and decryption can be done directly in the SDK. However, you need to pay attention to the local security protection of the encrypting key.

2. Data & files digital signature services

To realize the digital signature of data and files, the signer must have a signing certificate. According to the S/MIME standard, of course, the signing certificate must be bound to an email address, that is, every user (data producer or data user) must have an email address and must have a signing certificate bound to email address. Users can use their own signing certificate to digitally sign all kind of files or data files to prove the trusted identity of the data producer or user of this file. This is the same as the implementation of email digital signature. MeSign Cryptography as a Service can help users easily implement digital signatures of all kinds of files and data, as shown in the figure below.

Each user must have a signing certificate. The user submits a signing certificate application through the SDK. The certificate binds the user email address and user identity information. After completing the email control validation and identity validation, the signing certificate is issued to the user and stored in the SDK, and the signing certificate key generated locally by the SDK and securely stored in the SDK key store for digitally signing data and files. The application and configuration of a signing certificate for users only needs to be automatically completed by the SDK when the digital signature service is used for the first time.

The business system posts the data or file to be signed to the SDK, and the SDK is responsible for digitally signing the data or file with the user's private key to realize the digital signature of the data or file to prove the trusted identity of the data or file. In the digital signature process, a timestamp signature is usually attached at the same time to prove that the digital signature time is trusted and non-repudiation. The validation of the digital signature is to post the digitally signed data or file to the SDK, the SDK validates whether the digital signature and the timestamp signature are valid and trusted, and restores the original data or file to the user. The user will then rely on the result of the signature validation to determine whether to trust this data or file and whether to use this data or file.

The core of the data and file digital signature service is to make every data or file have a trusted identity. MeSign Technology provides 4 different identity types, and users can choose different identities according to business needs, including the V1 Identity that only validates the user’s email control, the V2 Identity that validates the email control and personal identity, the V3 Identity that validates the email control and organization identity, the V4 Identity that validates the email control and organization employee identity. Different identity validation levels need to complete the identity validation as required when applying for a signing certificate before user can use digital signature service. Of course, different levels of identity validation charge different fees due to the workload of identity validation.