Public Key Infrastructure (PKI)

To send an encrypted e‑mail to someone, you must first obtain that person’s digital certificate containing their public key. You can do so in one of the following ways:

• Request a signed e‑mail from your recipient and save the included certificate to your address book; or
• Search for the recipient’s digital certificate in the HKCA online d‑Cert repository (directory) by name or e‑mail address, and download their d‑Cert.

Here’s how to tell whether an email is S/MIME signed, encrypted, or both:

• Outlook (Windows/Mac)

Signed: A ribbon/seal icon; “Signed by …” with signature details. Message is readable.

Encrypted: A padlock icon; message opens only if your certificate/private key is installed. Without it, you’ll see an error or an unreadable attachment.

• Apple Mail (macOS/iOS)

Signed: Blue checkmark (verified) or red X (failed). Message readable.

Encrypted: Padlock icon closed (encrypted) or open (not). Requires your private key to open.

• Thunderbird

Signed: A signature badge showing “Good signature” or “Bad signature.”

Encrypted: A lock icon indicating encryption status.

If an e-mail message has been properly encrypted using the public key that corresponds to your private key, your S/MIME‑compatible e‑mail application will automatically decrypt the message once you enter the password to activate your private key and display it to you as plain text.

For two parties to exchange signed and encrypted e-mails, the following conditions must be met:

1. Both parties use S/MIME‑compatible e‑mail applications, AND
2. Both parties possess a valid digital certificate.

Once these conditions are fulfilled, the sender can digitally sign and/or encrypt messages by selecting the appropriate “Sign” and/or “Encrypt” options in their e‑mail application.

If the sender has included their public key certificate in the signed message, your S/MIME‑compatible e‑mail application will automatically verify the digital signature. In Microsoft Outlook, for example, a security icon labeled “Signed” will appear in the upper‑right corner of the message, indicating that the message has been digitally signed and verified.

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are cryptographic protocols that secure data sent over a network (e.g., HTTPS on the web). They provide confidentiality, integrity, and authentication between clients and servers. TLS and SSL are application independent, allowing other protocols like HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol), and Telnet to operate securely on top of them. These protocols negotiate encryption keys, and authenticate the server before any data exchange takes place at the application level. SSL (and its successor, TLS) maintains the security and integrity of the transmission channel through the use of encryption, authentication and session keys.

In PKI, encryption is the process of transforming readable data (plaintext) into unreadable data (ciphertext) so only authorized parties can read it. It uses cryptographic keys managed within the PKI. The same key can then be used to decrypt the message to its original form. Knowledge of the encryption key is necessary to carry out decryption. With the encryption techniques in use today, the security of the system is critically dependent on the length of the key used for the encryption. As encryption algorithms are publicly available, it is through the complexity (i.e., its length) and the secrecy of the key that the strength of the encryption can be assured.

A hash function is a one-way algorithm that transforms a message of any size into a fixed-length output called a hash (or digest). The hash function makes it impossible to revert to the original message and computationally difficult to find any two messages that hash to the same result. SHA-2 family algorithms such as SHA-256 and SHA-512 are common hash algorithms.

Public Key Cryptography or Asymmetric Cryptography forms the basis of digital signatures and Public Key Infrastructure. This technique makes use of a pair of mathematically related, but different keys – a private key and a public key. The private key is kept secret and is only accessible to its owner; the public key is intended  wide distribution. If one key is used to encrypt a message, then only the other key in the pair can be used to decrypt it. The public key can be used to verify a message signed with the private key, or to encrypt messages that can only be decrypted using the private key.

S/MIME (Secure/ Multipurpose Internet Mail Extensions) is a de facto standard for encrypting and digitally signing e-mail using public key cryptography and digital certificates. MIME is the industry standard format for electronic mail, which defines the structure of the message’s body. S/MIME adds a secure feature to the MIME standard. E-mail applications that support S/MIME add digital signatures and encryption capabilities to that format. Standardisation of the secured message’s format allows users to conduct private and authenticated communications, independent of the e-mail software they use, as long as this software is S/MIME compatible. You and your recipient must have public key certificates and S/MIME compatible e-mail applications in order to send and receive secured e-mail.

S/MIME uses the PKCS #7/CMS format to carry signatures and encrypted data. These appear in e-mail as .p7s or .p7m attachments, where .p7m contains the encrypted message and .p7s contains the digital signature file. If such a file is received as an attachment, there are 2 possible reasons:

1. Web-based e‑mail account: You may be using a web-based e-mail service. It is suggested that you access your e‑mail using a non web-based e‑mail client;
2. Non–S/MIME-compatible e‑mail client: You may be using an e-mail client which is not compatible with S/MIME and therefore cannot verify the attached signature. It is suggested that you upgrade your e-mail client to the latest version or use another S/MIME-compatible e-mail application (e.g., Microsoft Outlook, Mozilla Thunderbird, or Apple Mail).