BeSure — A realistic blockchain case for the Belgian government

Smals Research devised and developed in detail a blockchain application in the first half of this year. A comprehensive analysis was made, as well as a working proof of concept. This blog post explains the business case and approach at a high level.

The business case

Disclaimer: Different eBoxes are operational in Belgium. BeSure wants to provide a service that is as generic as possible. We therefore do not focus on a specific existing eBox.

Within the government, there exists an eBox platform used for exchanging documents between end users. There are different organizations that each represent a different, non-overlapping part of the end users (see figure below). Each end user is thus represented by exactly one organization. When Alice sends a message to Bob, the flow is as follows:

  1. Alice sends the message through her organization to the eBox
  2. Bob downloads the message through his organization

Alice and Bob use a web client or fat client offered by the organization representing her or him. The eBox must therefore be seen as a centralized exchange platform for documents to which various organizations are affiliated.

Now we would like to have proof that the document was sent by Alice at a certain moment, and that it was received by Bob at a certain moment. Those proofs must be stored and remain valid for 40 to 50 years. We can of course trust that the eBox will do this correctly, but in fact the end users and organizations do not trust the eBox sufficiently, nor do they trust each other. The end users, however, do trust their organization and want to stay far away from complex IT. A blockchain approach, in which the organizations are part of the blockchain network (the light blue circle in the above figure) is, hence, a logical approach.

Basic idea

In an ideal blockchain world, the end users themselves participate directly in the blockchain network. This, however, requires that they install, run and update the blockchain software when necessary. It requires that they generate a private key and protect it adequately. It requires that there is a way to manage the access rights, which is not easy with a large variable group of end users. End users would rather not be bothered with all of the above. That is why we propose an approach in which only the organizations and eBox participate. This is a relatively small, stable set of entities that have the possibility to participate in the blockchain network and that can make mutual (legally binding) agreements. In this approach, the end user does not even need to know that a blockchain is being used in the background. The price is that the trust is decentralized among a few entities, and not distributed among all the end users.

Two proofs are created per document: one that proves that a specific document from Alice and intended for Bob was sent to the eBox at a certain moment, and one that proves that the document was reretrieved from the eBox at a certain moment. Such a proof is in fact an agreement between the involved organization and the eBox. It is a blockchain transaction that is signed by these two parties. Hence, the creation of this agreement is a process between only them.

Then, this double-signed agreement is given to the blockchain network. Only if the transaction is signed by the eBox and one of the known organizations, it is collectively accepted by the network, and ends up in the blockchain, where it is unalterable. This is a collective process between the involved organizations. The eBox does not play a role in this step.

The figure below shows the content of such an agreement. First the cryptographic hash of only the document is calculated. The resulting document hash is hashed again, but now together with the identifier of both the sender and the addressee. This final hash ends up in the proof. Secondly, the proof contains a timestamp, indicating when the agreement was created, and thirdly the action; the document is delivered to the eBox (‘SEND’), or the document is retrieved from the eBox (‘RECEIVE’). These three elements are signed by both the eBox and the organization involved. Both parties only sign if they agree with this information. The blockchain network then verifies that the evidence is effectively signed by the eBox and a known organization, and is not interested in the content of the agreement. Note that the blockchain therefore does not contain any personal data, which is a concern less. This is not unimportant given the tension between the GDPR and blockchain.


What is the evidentiary value of such a proof? There are three levels, depending on the extra information we have.

  1. Without additional information, a proof only proves that an unknown document, with an unknown sender and unknown recipient, has been sent or received at a known time by an (unknown) end-user affiliated with an identified organization. This is what the participants in the network know in any case and says something about the activity of the individual organizations
  2. When we only have the document hash and the identifiers of the sender and addressee, we can prove that an unknown document, sent by an identified sender and destined to an identified recipient, is sent or received at a certain moment. This comes functionally close to both the traditional registered mail and the meta-data that telecommunications companies are legally obliged to store for a certain amount of time.
  3. If also the original document is know, we can additionally prove that exactly that document has been submitted to or retrieved from the eBox.

Such a granularity is useful. Even without disclosing the document, certain activity can be proven.


We obviously want to avoid that the eBox or an organization can cheat. Changing the document, sender, receiver, time or type of action is impossible thanks to the two digital signatures. But there are still other aspects remaining that should be taken into account.

  • We want to prevent the eBox from injecting false messages into the system. This would allow the eBox to send a document to Bob in the name of Alice.
  • We do not want that a document is sent to or retrieved from the eBox without the registration of a corresponding proof on the blockchain.
  • We do not want that a ‘proof’ is registered in the blockchain for something that has never happened.

This is not trivial in a context where the parties do not trust each other. Nevertheless, we were able to come up with a strong and realistic solution.

There is a tension between blockchain on the one hand, which relies on transparency, and on the other hand confidentiality. Although we only keep hashes in the proposed solution, it still contains a serious shortcoming in terms of confidentiality protection. The same hash is, after all, reused in all proofs related to the same document. As a result, these proofs can be linked trivially to each other, also by organizations that are not involved in the flow. They can see when an unknown document has been sent via a known organization, and when that document was received via another known organization. And if they do this for every document, they can extract potentially useful statistics from it. We were able to solve this too, taking into account even very subtle forms of data leakage through the blockchain.

A detailed explanation of all safety aspects would unfortunately make this blog post too long, but you are always free to contact me. We summarize a number of BeSure properties:

  • The system can deal with compromised keys. This is because for every action (rights management, creation of a proofs publication of a proof, and key management) multiple keys are required. This is makes it more resilient than centralized systems.
  • The blockchain does not leak confidential data, even in more subtle ways. Participants do not learn any sensitive information about each other via the blockchain. And when a hacker gains access to the blockchain or when the blockchain ends up on the street, this has no implications for the privacy of the citizen.
  • Key management is done with the blockchain. The participants are therefore not dependent on a PKI, which is organized in a top-down hierarchical way.
  • Crashing of a BeSure component does not result in (temporary) vulnerabilities.
  • When the recipient interrupts the download, eg. after 25%, no proof should end up on the blockchain. This seems logical, since there is no successful download. However, we should avoid that the recipient can already access a part of the document. BeSure prevents the recipient from being able to extract any information from the downloaded part until succesfull completion.
  • BeSure uses MultiChain as underlying blockchain technology. This is a fork of the Bitcoin code, which has already been extensively used and tested in practice. This results in a product with fewer bugs, which can therefore be considered as more stable and secure.
  • External validators can be added to the network. They are granted access to the blockchain / blockchain network and are co-responsible for processing the proofs in the blockchain and for securing the blockchain. This further increases the confidence that everything runs correctly.

In short, we realized a system that can guarantee a very high level of security.


A question we are often confronted with is: “Can’t we do this with traditional technology?” This is possible, but then we will depend on authorities. For example, in order to keep digital signatures valid for a long time, we need the cooperation of a time-stamping service each time a proof is created. In a traditional solution, we must also find a way to prevent the proofs from being lost or deliberately removed over the years. Will we also rely on a central service for this? So there are good reasons to consider a blockchain approach.

A lot of blockchain proofs or concept today will unfortunately have to be thrown away. Some blockchain companies ignore the GDPR, build blockchain proofs or concept that are not intended to run distributed (!), and ignore confidentiality requirements. For BeSure, in addition to a working proof of concept, we have made an extensive analysis. We also use a blockchain technology that has already been extensively tested in practice. thanks to the above combination, we significantly increase the chances that BeSure will be used in a production environment.

With the blockchain philosophy in mind, we can go one step further and question the very existence of the eBox itself as a central exchange platform. After all, we still have to trust that the eBox is available, that it keeps the documents confidential, and that it is not hacked. Although this will probably remain unrealizable in, say, the next ten years, it remains an interesting idea that I might work out in a future blog post.

Stay tuned! 🙂

[This is a translation of an article that has previously been published on]

Like what you read? Give Kristof Verslype a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.