arrow-left

All pages
gitbookPowered by GitBook
1 of 4

Loading...

Loading...

Loading...

Loading...

Digitally Sign Uploaded PDF

The user "has" a token and "knows" a PIN for the application of a digital signature using a PDF document

hashtag
References

For more in-depth details on the technical flow for PIN validation, check out:

hashtag
Introduction

A user can digitally sign a document using ReadMyCards

At the bottom of the page, there are 3 use cases available:

  • authenticate user with browser OR operating system pin dialo

  • upload a PDF document as a prerequisite to the process of performing a digital signature

  • digitally sign a PDF document

hashtag
Pin Dialog

The Trust1Connector ask the user for a PIN when performing an authentication or a digital signature. When a user enters the PIN in a browser dialog, the Trust1Connector has the necessary functions in the SDK to encrypt the PIN sent from the browser towards the Trust1Connector instance. The reasoning behind this approach is:

  • the Trust1Connector does NOT rust a local browser: the browser can be corrupted with a 'dirty' plugin for example; no pin code will be visible in the 'debug console' of the browser

  • applications are not trusted, except when presenting a valid token, and when performing a key exchang prior to the use of the connector

When enabling the toggle 'Use operating system pin dialog', you ask to ignore entering the PIN in the browser by delegating the PIN entry to the operating system. When this option has been enabled, the Trust1Connector will ask the underlying operating system to deal with the PIN entry. This means that the PIN entry is COMPLETELY separated from the web application or browser.

circle-info

This topic has different motiviations depending on the use case and security policies applied in an organizatoion. The Trust1Connector want to guarantee a safe implementation for both use cases mentioned

When the use case completes succesfully, in the top right, the following message will appear for a short amount of time:

hashtag
Digital Signature

The ReadMyCard application allows a user to sign a PDF document using baseline PAdES-LTV Profile (Long Term). It’s the long-lived signature format. This profile allows you to extend the validity of signatures in PDF format indefinitely. It can be used in conjunction with other PAdEs profiles. This profile is used to ensure validation many years after the completion of the signature. That is, it guarantees long-term validation.

Start uploading a PDF document, this can be done by selecting the 'file-drop'-zone or drag-and-drop a file to the 'file-drop'-zone.

Once a file has been uploaded, the filename will appear in the drop-zone.

Start the signature flow using the 'Sign uploaded document':

When the flow completes succesfully, the following pop-up will be shown:

From the pop-up you can:

  • download the signed PDF document (using the download link)

  • close the pop-up and go back to previous screen

Opening the document in Adobe Acrobat Reader, will demonstrate the application of the digital signature

Opening the signature details, the signature properties can be verified:

circle-info

There are no guarantees for the documented properites using the ReadMyCards application. As the application can be altered for demo purpose, some details can or may change over time

Card and Token Detail Page

Shows an overview of all information retrieved from a selected smart card or token

Starting form the readers page, when a token has been detected and recognized, a 'select' button can be used to start dumping all known information of the selected token:

hashtag
Biometric Information

The first section of the 'Card Details Page' shows a visual representation of the card, this contains the 'biometric' information from a card. Note that this information can be retrieved when:

the smart card or token has a custom application exposing this information

  • the smart card or token has basic user information in the certificates present on the tokenC

  • Visual representation of the selected token
    circle-info

    The visual representation can vary depending on the selected token type (each card type is called a 'module' in the Trust1Connector context.

    When a specific visual representation is not available for a given/selected token, the default visualization schema will be applied.

    Trust1Team can add new token visualizations to the connector's extension framework.

    The second part contains specific data for the selected token, and can vary depending on the schema used. In the given example, the address is not available in the card certificates, but is read out of the Belgian eID application directly. As this is feature which is not supported by all tokens, it is possible that the address is not visualized.

    User address information (if available)

    hashtag
    Certificates

    The next section displays all available certificates from the token

    Smart card or Token Certificates

    hashtag
    Certificate Details

    The certificate details perform a Certification Validation process. This is done using the Trust1Connector Validation Service, which is service hosted by Trust1Team.

    The service is performing all validation needed and returns a 'color-code' accompanied by a short descriptive on the reponse obtained by the valdiation service.

    The example, using the test card, shows a warning (as this is a test card):

    Test Card validation - warning

    When selecting the option 'Show Details', a short summary of the validation feedback can be obtianed:

    Validation Short Descriptive Feedback

    When performing the same flow with a valid card, the result is the following:

    Certificate Validation using production token

    hashtag
    Certificate Types

    The retuned certificates are in base64 binary format. Future releases of the ReadMyCards will parse the obtained certificate and show the resulting certificate properties in a readable format.

    The following ceritificate types are used by the connector:

    Certificate Type
    Description

    NON REPUDIATION CERTIFICATE

    The certificate which is used to perform a digital signature

    AUTHENTICATION CERTIFICATE

    The certificate which is used to perform an authentication

    ENCRYPTION CERTIFICATE

    The certificate used for encpryption/decryption of payloads

    ISSUER CERTIFICATE

    The certificate used for validation of the read card data

    INTERMEDIATE CERTIFICATE

    The intermediate certificate of the issuer

    circle-exclamation

    Some tokens can have multiple certificates of the same type. Those are returned form the Trust1Connector and can be used in the application context. In the ReadMyCards application, only one will be displayed.

    Read all information of a selected token
    Upload, authenticate and digitally sign
    Browser PIN dialog
    Operating system (MacOS in this example) PIN dialog
    Succesful PIN validation
    Upload PDF Document
    Uploaded PDF Document
    Enter PIN for digital signature
    Succesfully applied digital signature
    PDF validation using Adobe Acrobat Reader
    Digital Signature Details

    Test Pkcs11 library

    The Trust1Connector provides a way for user's to test out a PKCS11 library.

    Using the ReadMyCards application you can load your configuration.

    On the admin page you will be able to update the path towards a PKCS11 library.

    Here you must set this to the path where the Pkcs11 library is located on your system. Then click update

    Update the windows confugration path

    Then we go to the readers tab and use the pkcs11 module as an override

    Next up click Select for the reader and it will use the define PKCS11 library to try and read the card information

    User Authentication

    The user "has" a token and "knows" a PIN code

    hashtag
    References

    For more in-depth details on the technical flow for PIN validation, check out:

    hashtag
    Introduction

    A user authentication can be executed from the ReadMyCards application.

    At the bottom of the page, there are 3 use cases available:

    • authenticate user with browser OR operating system pin dialog

    • upload a PDF document as a prerequisite to the process of performing a digital signature

    • digitally sign a PDF document

    hashtag
    Pin Dialog

    The Trust1Connector ask the user for a PIN when performing an authentication or a digital signature. When a user enters the PIN in a browser dialog, the Trust1Connector has the necessary functions in the SDK to encrypt the PIN sent from the browser towards the Trust1Connector instance. The reasoning behind this approach is:

    • the Trust1Connector does NOT trust a local browser: the browser can be corrupted with a 'dirty' plugin for example; no pin code will be visible in the 'debug console' of the browser

    • applications are not trusted, except when presenting a valid token, and when performing a key exchang prior to the use of the connector

    When enabling the toggle 'Use operating system pin dialog', you ask to ignore entering the PIN in the browser by delegating the PIN entry to the operating system. When this option has been enabled, the Trust1Connector will ask the underlying operating system to deal with the PIN entry. This means that the PIN entry is COMPLETELY separated from the web application or browser.

    circle-info

    This topic has different motiviations depending on the use case and security policies applied in an organizatoion. The Trust1Connector want to guarantee a safe implementation for both use cases mentioned

    When the use case completes succesfully, in the top right, the following message will appear for a short amount of time:

    ROOT CERTIFICATE

    The root certificate of the issuer

    Upload, authenticate and digitally sign
    Browser PIN dialog
    Operating system (MacOS in this example) PIN dialog
    Succesful PIN validation
    Flow Diagram
    Flow Diagram