Imagine you go to an event and just before the entrance you see a QR code with the heading “Check-in here” along with the organiser’s logo. As you scan the QR code with your Wallet, you are asked for your payment information, among other things. But should you present this information?
When we communicate with third parties over the internet, it is not always clear whether the other party is really who they say they are. This problem also exists with established communication channels such as websites and emails, among others. Phishing refers to the fraudulent tapping of data to gain access to bank accounts or similarly sensitive accounts or information. A permanent communication channel that allows users to identify the communication partner to enable a trustworthy exchange of information is essential to protect users from phishing.
Context is important
We often base our trust in an interaction on the context in which we are communicating. For example, we trust a link in an internal employee portal more than a link in a promotional email. The principle is the same when a contact wants to connect with users and the connection request is displayed in the wallet. Depending on the context in which the connection request is initiated, a different level of trust can be assigned. The context helps us to establish trust but is not sufficient on its own. Often the context is missing or attackers specifically try to exploit it.
Authentication of organisations
Wallet users must be able to check the authenticity of organisations they connect to. However, the organisation must first be identified and verified. Once the organisation has the required certificates it can be validated in the user’s wallet.
Hence, before the wallet can verify the organisation, a trusted party must certify the organisation. Certification authorities are organisations that are entrusted with signing digital certificates. They verify the identity and legitimacy of the organisation and the person requesting a certificate. If the check is successful, a signed certificate is issued. This certificate can then be verified by the user’s application such as a browser or wallet to authenticate the organisation.
Trust on different levels
An encrypted communication channel between individuals and organisations allows sensitive information to be exchanged without third parties being able to read it. However, this is not sufficient, as the identity of the other party must be verified beforehand. To ensure that the contact is really a public authority, for example, we use certificates to verify their identity. Consequently, there are two levels of trust. On the lower level, there is a cryptographically secured communication channel. This is supplemented by certificates issued by different certificate authorities or trust domains.
Certificates and trust domains
The basis for trustworthiness is that the certification authority implements organisational and technical measures at an appropriate security level and establishes rules for all participants in the trust domain. The specific requirements for the certificates depend on the use case and the legal framework in which a transaction takes place. Thus, the certificates used can differ depending on the level of trust required for each use case.
Regulated certificate authorities act as issuers of certificates that certify the legitimacy of the domain holder and the security properties of the certificate. The signatures of the certificate authorities essentially serve to confirm the legitimacy of the certificate holder’s identity and to create trust in online data transmissions. Generic requirements for certificate authorities acting as a certification authority with the security level “high” are described by the Federal Office for Information Security of Germany in the Technical Guideline TR-03145–1.
Certificate verification in the Lissi Wallet
We would now like to transfer the approach of certificate verification, which we have known so far from web browsers, to the world of SSI wallets and have integrated a corresponding verification concept into our Lissi Wallet. The Lissi Wallet checks the certificates sent by the contact or agent. If an extended validation certificate is sent, the Lissi Wallet checks that the name of the contact/agent matches the name in the certificate. Only if there is a valid extended validation certificate and the name of the contact/agent matches the name in the certificate, the contact is displayed as verified.
Display of trusted contacts for users in Lissi Wallet
When a new contact request is made, users are asked whether they want to connect to the contact. In addition to the display of whether a contact could be verified, a recommendation for action is also given to the user. Further information on the contact’s certificate can also be displayed.
When users receive a connection request (fig. 1), a new proof (fig. 2) or a information request (fig. 3) in the Lissi Wallet, it is displayed whether the contact is verified.
The trade-off between self-sovereignty or maximum security
Would we rather have a high level of security or self-sovereignty? Unfortunately, the two aspects are at different ends of the spectrum. If we only allow pre-verified and approved parties to retrieve identity data, as currently envisaged by the eIDAS regulation, this severely restricts usage. Allowing users to share their data on their own responsibility offers more flexibility and freedom, but also potential for attack.
Lissi provides convenient applications for companies and organisations to receive, organise and share trusted data from end users while respecting privacy and data sovereignty. This includes the Lissi Wallet as well as our applications for organisations. You can find more information on our Website.