Privacy Sensitive Data Exchange

Privacy Sensitive Data Exchange

KeyTalk secures the data exchange between users, portals or systems and apps communicating with them, based on a Two-Way SSL.

Talk with a PKI expert

    For the exchange of (very) sensitive data, the classic HTTPS connection is not sufficiently secure. With KeyTalk CKMS it is possible to add extra security: with the help of user certificates, a Two-Way SSL is created. Possibly with Two Factor Authentication (2FA), based on a device or token. This makes, for example, man-in-the-middle attacks no longer possible.

    How does it work in practice?

    On the user side: users download the KeyTalk app and log in with their usual credentials. The app then picks up a certificate and key pair and installs it automatically on the device. On this basis, the user has access to the portal or backend system. As long as the certificate is valid, there is no need to log in again.

    • KeyTalk is linked to the AD, and authentication with Kerberos is also possible. If necessary, hardware recognition can be set as a second factor (2FA), so that users can only log in with a familiar device.
    • The period of validity of the certificate can be set per-user or user group. The user only has to log in once during the validity period (for example a day or a week), the rest of the validity is authenticated automatically via the certificate.

    Free internal private certificates (and keys)

    KeyTalk can be linked to external public CAs such as GMO GLobalSign or Digicert QuoVadis. For internal usage we provide you with a nice alternative: KeyTalk’s internal CA generates free (!) internal private certificates (and keys) Expensive public certificates are therefore no longer necessary.

    Technical details

    Applications that support client certificate-based authentication (such as Outlook/Exchange (Online), SharePoint, IIS, Apache, TomCat and many others) can be configured to request this. Usually, this is done on the basis of one or more explicitly trusted CA source(s) and a (user) name in the certificate.

    The application will use a public-private key handshake to establish the connection and validate the data of the client certificate that was offered.

    Once everything is found to be correct by the server and the application, a two-sided SSL authenticated connection or TLS will be set up with most applications. This will even protect you against Man-in-the-Middle attacks (MITM attacks) such as Modlishka.

    Would you like to know more?

    Do you wish to be provided with a demo, Proof of Concept or directly technical in-depth consultation with one of our PKI experts? Feel free to contact us, we are happy to think along with you!