(NL) Maak kennis met het dark web!
Het dark web roept vaak beelden op van illegaliteit, maar wat schuilt er werkelijk achter de anonimiteit? Roald Santens (Smals Academy) en Vandy Berten (Smals Research) nemen je mee op een verkenningstocht door de krochten van het internet. Je leert hoe de techniek achter anonieme netwerken werkt, wat de gevaren zijn voor organisaties, en waarom het dark web ook waardevolle kansen biedt. Kijk en luister hier waarom (Frans gesproken, NL ondertitels zijn beschikbaar).

(FR) À la découverte du dark web !
Le dark web évoque souvent des images d’illégalité, mais que se cache-t-il réellement derrière cet anonymat ? Roald Santens (Smals Academy) et Vandy Berten (Smals Research) vous emmènent explorer les profondeurs de l’internet. Vous découvrirez le fonctionnement technique des réseaux anonymes, les dangers pour les organisations, ainsi que les opportunités précieuses que le dark web peut offrir. Regardez et écoutez ici pour découvrir pourquoi.

(EN) Discover the Dark Web!
The dark web often evokes images of illegal activity, but what truly lies behind that anonymity? Roald Santens (Smals Academy) and Vandy Berten (Smals Research) take you on an exploration through the depths of the internet. You will learn how the technology behind anonymous networks works, the risks organizations face, and why the dark web also offers valuable opportunities. Watch and listen here to find out (French speaking, EN subtitles available).

General description

Our health is precious. And our personal health data is among the most precious information. So we need to protect it! Smals – the main IT provider for the Belgian public sector – already had strong security measures in place, such as firewalls, hardware security modules, SIEM systems and database encryption. Yet we do more.

eHealth’s blinded pseudonymization service (Intro in Dutch or French) adds an extra layer of security. It enables Smals to manage for example electronic prescriptions without ever learning to whom they belong, without knowing the social security number. Instead, Smals only sees unique codes (pseudonyms). Even if leaked, a hacker won’t be able to do much with the data.

The blinded pseudonymization service – managed by the Belgian eHealth-platform – ensures that only an authorized health care professional, such as your GP, can link a prescription to you. It’s blind, because it doesn’t see any pseudonyms or social security numbers.

We can’t simply encrypt all the data before sending it to the backend, because the latter has functional responsibilities, such as input validation and generation of statistics. Our approach enables the selective encryption of some of the data fields (e.g., free text by the GP), such that the backend only has access to the data it needs in order to fulfil its assigned tasks, without ever seeing social security numbers.

This elegant and versatile approach greatly reduces identification risks in case unauthorized (internal or external) entities obtain access to centrally stored medical data. This approach is the default choice for new e-health applications in Belgium. It is already in use today for electronic prescriptions and information about vaccines, prosthetic devices, fertility, allergies and intolerances. The latest application to use this service is TRIO to assist disabled persons. It is a successful example of privacy by design in the Belgian public sector.

Can you briefly describe the solution, product, technology, approach, or project?

The Belgian eHealth ecosystem consists of multiple backend services which store different types of medical data. Some examples are prescriptions, vaccinations and therapeutic relations. These backend services are contacted by citizens, health care professionals and other eHealth backend services. While Smals manages the backend services, eHealth manages security services (e.g. access control).

On top of the existing security measures, we introduced a new security layer guaranteeing that social security numbers are no longer exposed to backend services or their underlying infrastructure. The blinded pseudonymization service, managed by eHealth, was introduced.

The solution cryptographically guarantees that:

• Backend services learn backend-specific pseudonyms, but never social security numbers.
• Authorized health care providers (such as your GP) learn social security numbers, but never pseudonyms.
• The pseudonymisation service learns neither.

Hence, each party only learns the strictly minimal identifier-related information it needs to know.

The system is versatile; It also enables selective encryption to ensure that the backend service only sees the minimal required personal (yet pseudonymized) medical data to fulfil its responsibilities. Additionally, our approach enables to flexibly and securely pseudonymize and join (intro in NL and FR) data originating from different sources for scientific purposes (e.g. epidemiology) by research institutes (such as Sciensano in Belgium).

Can you demonstrate its innovative character?

Storing the unencrypted data and the social security number in databases is a bad yet common practice. Unauthorized access could have detrimental consequences.

Experience taught us that full encryption of all data by the client, and storage of the resulting ciphertexts by the backend under the unencrypted social security number, comes with serious functional limitations. The backend could indeed no longer validate the correctness of incoming values (e.g. medication codes) or extract statistics.

Therefore, we need a finer-grained approach that hides social security numbers as well as some of the medical data (e.g. free text written by the doctor).

Adjacent academic work exists. Notably, there is the polymorphic encryption and pseudonymization by Verheul et. al. While this pseudonymization service is located between the health care professional and the backend service, ours sits at the sideline. Consequently, our solution respects existing communication flows. Moreover, in contrast to the solution proposed by Verheul, the blinded pseudonymization service is unable to convert pseudonyms or ciphertexts into something decryptable by unauthorized entities. In summary, our service is less intrusive and requires less trust.

Springer Nature accepted in its 2025 volume Public Governance and Emerging Technologies our chapter discussing the blinded pseudonymisation service.

What is the added value of this security innovation in terms of security: how resilient and protective is it?

Security & Privacy

The solution greatly reduces the identification risk in case of an internal adversary (administrator) or external adversary (hacker) having access to or publishing the medical data stored by the backend service. The social security numbers, as well as a subset of the actual medical data in each separate record, remain hidden. It enables Smals to implement the principle that it should nowhere in the process have access to social security numbers. It is adopted as the default approach for new IT projects in Belgian healthcare and social security.

Our solutions greatly reduce identification risks, but does not reduce them to zero. It should be seen as an extra – but strong – layer of security, on top of the existing ones (such as access control, database encryption and firewalls).

High availability

The high availability of the pseudonymization service is guaranteed by the deployment of multiple instances and HSMs in multiple datacenters. Moreover, a backup solution is foreseen, offering limited functionality when the pseudonymization service is unavailable.

Correctness

The correctness of our solution has been validated by academic partners.

This is a submitted contribution by Kristof Verslype, cryptographer at Smals Research. It was written in his own name and does not take a position on behalf of Smals.

Featured image by Cybersec Europe

Cryptography is essential in our society to secure sensitive communications and financial transactions, among other things. Cryptographic recommendations help organisations and teams decide when certain cryptography in their systems should be phased out and replaced. Expressing such cryptographic recommendations as a code has advantages, such as an increased degree of automation and increased insight, and is a logical step towards cryptographic maturity.

Cryptographic recommendations

The recommended algorithms and parameters, including key lengths, for authentication, digital signatures, cryptographic hash functions and symmetric encryption, among other things, change regularly. Algorithms that were once recommended are now insecure. The same applies to cipher suites in communication protocols such as TLS. Cipher suites are combinations of cryptographic algorithms and parameters agreed upon by the communicating parties. On this basis, a secure channel is then set up.

In many countries, including our neighbours Germany, France and the Netherlands, the national information security agencies publish detailed recommendations on the use of cryptography. Usually a distinction is made between cryptography that is recommended, cryptography that is not recommended but is still considered secure, cryptography that we should phase out and, finally, cryptography that is insecure. Those recommendations are regularly updated. The German BSI does this on an annual basis, for example.

We still lack such recommendations in Belgium. These should ideally be formulated at European level, by ENISA, the European Union Agency for Cybersecurity, for example. Unfortunately, we are not there yet. At the same time, Smals and the Belgian public sector certainly have a concrete need for them today, which is why Smals Research took the initiative a few years ago to formulate its own internal recommendations. These are based on the recommendations of the German BSI, as it is the leading and best subsidised cyber security agency in Europe.  

Recommendations as code

As with all other cryptographic recommendations, these are currently expressed in a way that is legible to humans, but not sufficiently structured to allow processing by machines. The latter would allow a higher degree of automation and could improve security.

• It could allow to automatically generate the cryptographic part of the configuration files for communication protocols such as TLS and OpenSSH. As a result, updates could be implemented faster, with less manpower and less risk of human error. Smals uses hundreds, if not thousands, of machines that must be able to communicate securely.
• This would allow us to unlock the cryptographic recommendations interactively. A project team would be able to quickly consult the most recent cryptographic recommendations relevant to them via a web interface. Once the application is live, a project team would automatically be kept up to date on changes relevant to them.

The closest thing available today is the website CipherSuite. While this is a commendable initiative, we would prefer to proceed with Smals for several reasons. After all, we do not necessarily follow these recommendations, which are also limited to the TLS communication protocol. We also want something that is CBOM compatible.

Cryptography Bill of Materials (CBOM)

In the context of the threat posed by powerful quantum computers, another major crypto migration is becoming increasingly urgent. In order to prepare for this and other future migrations, organisations would be wise to start building an overview of which cryptography is being used where. This would allow them to draw up a well-founded migration plan and will also make the migration itself run more quickly and smoothly. This inventory quickly becomes very complex and is therefore ideally expressed as code to facilitate automatic updating and processing by machines.

To this end, IBM developed CBOM (Cryptography Bill of Materials), which allows cryptographic components such as algorithms, parameters, protocols and libraries and their dependencies to be expressed in JSON. It is an OWASP CycloneDX standard, which means that it is compatible with SBOM (Software Bill Of Materials), among other things. CBOM allows us to take the management of cryptographic assets (algorithms, protocols, libraries, keys, certificates, …) to the next level.
The illustration below is a CBOM fragment that shows where RSA-2048 is used in the scanned source code of an application.

Suppose an organisation expresses its cryptographic assets as CBOM, and has cryptographic recommendations in code compatible with it. That organisation could then very quickly determine where and to what extent it complies with the cryptographic recommendations, or not. This insight could be particularly useful when taking steps to make the organisation and the data it protects more secure. An organisation could then quickly find out where it is most vulnerable to powerful quantum computers. The organisation can also quickly provide exact information during audits, for example in the form of an automatically generated report in PDF or Excel format, in response to specific questions from the auditor.

Deviations as code

Aside from the recommendations and the cryptographic assets, there is a third element that can be expressed as machine-readable code: the deviations from those recommendations.

In an ideal world, Smals would systematically and solely use the recommended and secure cryptography in its systems. This is not always possible, given that it would de facto make services unavailable to the users of those systems. We cannot expect doctors, pharmacists, physiotherapists, Public Welfare Centres, etc. to support only the latest secure cryptography at any given time. Smals must therefore show a certain degree of tolerance whereby it continues to support sub-optimal cryptography for a limited period of time. This should be done in a structured manner, with a limited tolerance period and with the risks clearly assessed by security services and approved by management.

This too is best expressed in a way that allows automatic processing. Combined with the recommendations and inventory, this allows us to see immediately where we deviate from the recommendations, both documented and undocumented. This approach also provides insight into the cumulative risk, which helps increase safety in the organisation. This, too, can be useful in audits.

Conclusion

A few years back, Smals Research made a proposition for cryptographic recommendations, which was adopted by Smals and is updated at least annually. Smals Research believes the time is ripe for the next step and is currently converting these recommendations into a structured form with a maximal compatibility with CBOM. The same is done for deviations from those recommendations.

CBOM and Smals’ ambitions to express cryptographic assets, recommendations, as well as deviations in a machine readable format fit into the broader trend of Everything as code, a philosophy that results in an increased degree of automation of processes and management. This gives us more insight and allows us to better anticipate and intervene if necessary. Moreover, it results in increased consistency and scalability thanks to reduced human intervention.

Applying Everything as Code to cryptography is, in our opinion, an important step in increasing cryptographic maturity. We therefore see CBOM as a necessary standard that we expect to see increasingly supported in tools for development, information security and post-quantum migration in the coming years. Consequently, we expect vendors to increasingly provide a CBOM with their software, hardware or services.

We expect the triumvirate of cryptographic assets as code, recommendations as code and deviations as code to unlock new possibilities and opportunities for insight and automation. One idea is to perform graph analytics (graph analytics) on this data, ideally using a graph database supplemented with an interactive visualisation tool.

To be continued. Please do not hesitate to contact us if you are interested.

This contribution was submitted by Kristof Verslype, cryptographer at Smals Research. It was written in his own name and does not represent Smals’ position.

These methods prove particularly pertinent within the framework of European regulations concerning data protection and the use of shared IT infrastructures. Indeed, confidential computing may help mitigate the trust issue concerning third-party or foreign providers, notably those based in the United States.

This talk presented at Voxxed Days Brussels delve into the primary techniques, scrutinising their functionality, advantages and limits.

Presentation

Link to the pdf document: Download

1.   Introduction, Goals, Context

During the Covid19 pandemic, Belgian government IT services responded quickly with solutions to administrate tracking, tracing, and eventually vaccination of citizens. An important pillar of these projects was, and remains to this day, the option to send someone a short message with an instruction or other important info, such as a PCR code. The obvious answer to implement this capability, was the use of the cell phone network’s Short Message Service (SMS).

Using SMS, we were able to reach millions of people expediently. The expense, however, was proportionate. At some point during the crisis costs rose to a very high level, and they are expected to remain high for some time. This problem was seen as one of several linked to the chosen approach. SMS, all things considered, is a technology over 30 years in age, and has other disadvantages. For example, the texts are sent in clear text, readable by intermediaries, such as the carrier. Also, in and of themselves, they only allow for purely textual content, not multimedia. Guarantees with regard to the identity of the person receiving the messages could be enhanced. The use of the mobile phone number had a good fit with the tracking and tracing use case, but did not enable a more general adoption for government communications.

A solution based on mobile applications (Apps) has therefore been conceived. There are many examples of Apps being able to receive messages, containing any kind of content, over the internet, and informing the user with a timely notification. The conceived solution can reduce dependence on SMS and replace many other communication channels. In future embodiments, it will evolve towards a reusable service, operating as an App, capable of centralizing a citizen’s communication with government services entirely. To expedite adoption by as many people as fast as possible, the first embodiment will leverage the existing CovidSafeBe App, already installed on 8.5 million smartphones, using it to encourage the public to install the new communications App.

2.   Solution description

The concept includes integration of the following technologies in order to provide an integrated and secure communications system:

• Fully service oriented design, disclosed by APIs, where the central SMIS (see section 4) governs which channels are used to contact a citizen, and several other services control only a specific channel (such as the Mobile App channel, but also, non-exhaustively, SMS and e-Mail).
• Integration with secure mailbox systems such as e-Box, so messages can contain a link to a document in the e-Box that, when clicked on, can open that document in a mobile App.
• Integration in a digital wallet.
• Identification of the citizen based on a high quality identity scheme and base registry such as used for the NISS number.
• Strong authentication mechanisms such as ITSME.
• End-to-end Encryption between an eGovernment system that sends a message to a citizen, and that citizen’s device, which means the SMIS will only know the sender and the channel preferences, and any service specific to a channel will only know where it is sending a message.
• A pseudonymization system, meaning that the SMIS does not know the addressee and the initial sender does not get additional information about the addressee (such as phone number when only the NISS is known, or vice versa).
• Asynchronous feedback, e.g. via an event subscription mechanism, making it possible to alert a sending application when a message delivery was attempted, when it was successful, and perhaps even when it was read.
• A broadcast mechanism, allowing messages to be sent to groups of people or even the entire country.
• Automated code of conduct imposed on applications using the messaging service, so that citizens do not feel they receive too many messages of little significance.

3.   Initial embodiment

A thorough description of the solution requires us to make a distinction between a short-term strategy, a first embodiment focused on mitigating the SMS expenses currently involved in dealing with the pandemic, and a longer-term strategy, with further embodiments focused on streamlining the eGovernment’s communication with its citizens.

For the short-term strategy, the high-level architecture for the entire implementation is depicted in Figure 1. Key to our approach is the development of a number of centralized, reusable services, and the development of a mobile Application to receive messages for a citizen. For the first embodiment, an initial version of the “Short Messaging Integration Service” (SMIS) meant to unify the use of all communication channels towards the end user, will be built. Furthermore this first embodiment includes the mobile Application itself, plus a second service, specifically meant to drive the transmission of messages, coming from SMIS, towards this App.

3.1.      Short Messaging Integration Service

The Short Messaging Integration Service (SMIS), one of the central components in this solution, will receive messaging requests, via a REST API, from three already existing services (PLF, CTPC and the Tracing BP engine).

The SMIS will be able to use the Mobile App Messaging service or the existing service by RingRing, to send its messages. The primary scheme will be to first try to send a message via the App, and to fall back to SMS, should the former fail for some reason.

On the picture, you can also see the Paloma service. It is yet to be decided whether that service will use the SMIS in the first embodiment or in (one of the) later embodiments.

3.2.      Mobile App Messaging Service + App

The basic functionality of the App in the first embodiment is relatively simple: it will serve to receive and display short messages coming from a government institution, containing text and certain media, such as two-dimensional images, allowing, for example, the depiction of QR codes. It will also employ the smartphone’s functionality called “notifications”, giving the end user an immediate audiovisual queue when new messages are received.

To steer the transmission of messages, a central component is required: the Mobile App Messaging service. This will be a reusable service, offering the capability to other services to transmit a message to an individual citizen. The first implementation of this service should also provide the following immediate feedback to the calling service: whether the App is installed for this citizen, and whether they have the notifications turned on or off at that moment.

3.3.      Authentication and Security

To be able to receive a personal message, a citizen will need to provide some form of identification. There are two possibilities here: phone number, or NISS.

Since for the initial embodiment, SMS is used, the short term strategy will focus on the former, using a simple mechanism often used to confirm an end user’s phone number. The user will register their phone number in the App. A confirmation SMS will then be sent with a unique code. The user then has to fill in this code in the App to prove they are the owner of the phone number.

4.   Expected benefits of the complete solution

• Cost benefits due to reduced number of SMS messages.
• High quality identity based on government base registries.
• Strong authentication based upon high quality identification.
• Privacy protection with encryption and pseudonymization.
• Integration with multiple business systems and multiple administrations.
• Integration with multiple services, e.g. eBox or digital wallet.
• Communication from multiple administrations to mobile systems form multiple recipients without knowledge of the phone number of the device.