What is a Public Key Infrastructure ?
A public key infrastructure (PKI) is a construct (made out of systems, software applications, processes, procedures, organization and people) that generates unique pairs of encryption / decryption keys (one private and one public key), binds them to an electronic identity and provides an electronic certificate (standardized electronic file) to certify that binding. The private key always must be kept secret, the public one not.
Each one of the two keys can be used to encrypt and decrypt data.
A key property of PKI infrastructures is that data encrypted with one key can be decrypted with the other key, the latter being the only one enabling to decrypt the data.
What are PKIs used for?
PKIs can be used to authenticate persons and objects as well as to electronically sign data.
To authenticate an person (e.g. let’s say Helen) over the Internet, you can simply generate a challenge (a random number), encrypt it with her public key and send her the encrypted challenge. You then ask her to decrypt the encrypted challenge with her private key (that only she knows) and then to send back the challenge after she has re-encrypted it with your public key. If the data you decrypt with your private key (that only you know) is the challenge you initially generated, then you are sure that Helen is the person she pretends to be. In fact, no other person is in a position to decrypt the encrypted challenge you to sent her.
To sign a text (which typically includes a statement of consent or agreement) of any size, a signatory can simply map it to data block of fixed size, called the hash, then encrypt the hash with her / his private key and thereby bind (e.g. embed) the encrypted hash with the original text.
- In PKI infrastructures, the time required to encrypt a text increases with the size of the text. This is the reason why, prior to signature, a text is mapped to a data block of fixed size, which can then be encrypted in a reasonable time span.
- The function used to do the mapping is public. It is important to note that the probability that two different texts generate the same hash is basically zero, even if the difference is quite minor.
To check the signature, one decrypts the encrypted hash with the signatory’s public key and compare it with the text’s hash (feasible, because the hash function is public). If the two hashes match, then the signature is valid.
Note that an electronic signature allows to:
- Guarantee the integrity of the signed text.
- Guarantee the authentication of the signatory.
The LuxTrust qualified certificates are first signed by the LuxTrust Global Qualified CA certificate, which is signed by the LuxTrust Global Root certificate.
The LuxTrust normalized certificates are signed by the LuxTrust Global Qualified Root certificate, which is signed by the LuxTrust Global Root certificate.
Such a certification tree also allows all LuxTrust certificates to obtain automatic international recognition in the most common browsers as well as in many other applications.
The framework just described, as it can be observed, requires the individual identification, typically face-to-face, in order to check the real person or legal entity identity so that an electronic certificate can be issued and provided.
Therefore, LuxTrust has partnered with IDNow in order to offer remote identification with the help of video technology. The process is completely run remotely through an identification service helpdesk. See our identification service for more details.
Obviously, in today’s world it is no longer acceptable to have proprietary solutions that do not interoperate or form closed environments when it comes to electronically sign and verify documents and transactions.
To achieve this interoperability goal, the European Commission mandated that the European Telecommunications Standards Institute (ETSI), a non-profit organization, elaborates technical standards for the eIDAS framework. This resulted in the establishment of an entire ecosystem for creating and validating AdES’s. Syntactical standards were adopted for encoding AdES’s: two prominent examples are XML Advanced Electronic Signatures (XAdES) and PDF Advanced Electronic Signatures (PAdES).
Which AdES standard is the most suitable?
It all depends on the use case.
XAdES is encoded in a readable textual format that complies with the rules of XML (Extensible Markup Language). Yet XAdES can be employed for signing any type of electronic document or data including XML-formatted documents like SEPA transactions. Other document types include PNG or JPEG pictures, any binary data, and PDF documents.
Multiple documents can be logically grouped together and signed using a single XAdES. Another XAdES feature: Two different signatories can sign the same document or groups of documents in parallel or alternatively in sequence.
PAdES is more restricted compared to XAdES: it can only be applied to PDF documents. A PAdES structure is always embedded within the signed PDF document and can only be used to sign a single PDF document at a time. Parallel signing is also not feasible with PAdES. Also, PAdES suffers from a historical design issue which creates logistical inconvenience for producing a PAdES. However, PAdES is currently more widely used due to the popular reach of PDF documents and its embedded security features.