Joint European Pension Insurance Registry — without a Central Authority

Cooperation between peers — the blockchain registry

Fragmented registries

The society of the 21st century has changed a lot since the modern social security pension systems were introduced about a century ago. The labor mobility has significantly increased, eligibility is earned in several different ways. Beside the classic full-time labor contract, people has more parallel relationships where they acquire pension rights, even in different countries. If the current trend continues, sooner or later majority of employees will work in more than one country during their career. The nature of employment relationships is diverse. Besides the classic ways new forms are spreading: increasing demand for experts are temporary in project like operations. It neither encourage companies to establish permanent positions nor attract specialists for long time commitments. This is why the social insurance records of a four-decade career shall be collected from several databases of several countries. In such a case, several pension insurances consider a single claim, and the decision can take a period of up to one year. The insured people are vulnerable to the fragmented registry.

?

These are the problems the insured person will face to on claiming benefits:

• Which is the competent pension institute(s) to submit the claim application?
• Will this institute contact others to collect the data records related to her/his earned eligibility?
• What if he/she don’t know which insurance institute is currently responsible to register the more decades old data of an early employment of the career.
• What if he is uncertain about the country the pension insurance contribution was registered and paid? (e.g. Which country was the employer affiliate company registered in, in case of a multinational company?)
• Has she lost the claims where she does not remember the employer’s data that is sufficient to identify the company and the belonging pension institute?
• If not, how can she obtain the certified data? Do the same certification rules apply everywhere? E.g. the old authentic document is accepted? Should she present a payroll record for every month of employment back to forty some years if the pension registry is missing them?
• How many claims should be submitted at different pension institutes? How many of them will disburse the pension in parallel?

?

This paper only deals with those problems which are related to the fragmentation of the pension insurance data registries, and related to the lack of trusted records and transparency controlled by the insured person.

The necessity of a single registry and the protection of privacy

All economic events, including those about employment, must be documented in written form across Europe, therefore all that an insured person has to do is to file all documents holding social security related data throughout her life (e.g. paper or electronic monthly payroll notifications). But there are still two problems: people does not file monthly payroll notes for a life and the credibility of such an e-mail is not assured for decades (legally not assured for the moment is was sent). The reader cannot decide from a file without electronic signature and timestamp whether it was created five minutes or forty years before. Furthermore, the pension insurance institute (PII) is responsible for the later payment of the pension, not the employer, so it is more suitable if the proof signing on the data record is from the PII.

The solution seems to be simple: if all pension eligibility related data is stored in a single database with a trusted electronic signature in EU, and if the responsible PII has access to these records when the amount of the pension is to be calculated, the problem is solved trivially. But this solution raises new problems:

• Who is authenticated to write into this database?
• Who is authenticated to read this database?
• Who is handling these authentications?
• Who is the database operator? Who grants and revokes rights?
• Who is the database admin?
• Who makes decision in case of a dispute?

Such a database shall hold all social pension insurance eligibility related data of Europe. These are information about employment, income, pension insurance contribution, marital and health status. All are the subjects of the 2016/679/EU General Data Protection Regulation, and are ordered to be protected. If someone’s full career is entered into an international database, including all companies he ever worked at, salary, marital status, the children’s birth data and all health status if relevant to the expected pension, then this person wants to be sure that the only one who can read a specific record is the competent pension insurance, who is responsible to store that record anyway. An employer also insists its data to be protected on a way that only the authorized office shall know the company’s financial ability to pay contributions in time. Briefly, the same actors can only get access to the data as in the current system. We have come to the conclusion that the data stored in this database should not only be trusted in legal meaning, but also has to be encrypted.

The legally trusted data mean that the pension insurance responsible to register and store the eligibility data, that will prove the right to get later the pension, has to electronically sign the record according to the 910/2014/EU (eIDAS) regulation. Article 25 (2) says that “a qualified electronic signature shall have the equivalent legal effect of a handwritten signature”, and (3) of the same article is that “a qualified electronic signature based on a qualified certificate issued in one Member State shall be recognized as a qualified electronic signature in all other Member States”. This means that if the signatory is identified according to eIDAS and the signature (and time stamp) connected to the record also complies to this regulation, then it is legally trusted in all EU member states (and all legislations where eIDAS is recognized). Time stamp proves that the data and the belonging signature existed before the moment the time stamp was created (e.g. the record existed forty years ago and was not created yesterday).

The obligation to encrypt data means that it has to be stored on a way that only that person can recognize it who is related to it (e.g. the insured person) and only that pension insurance who is authorized to store it regardless of this system. It is not efficient if a record is containing only encrypted data, because it would be difficult and resource consuming to locate it later. The insured person, the economic operator (employer), the pension insurance related to the employment and other authorities or organizations who provide relevant data to the calculation of the amount of the pension (health service providers, tax authority etc.) need “write access” right to the database. It makes sense to refer these actors using unencrypted identifiers. It is essential, that the identifier for employers, pension insurance institutes and authorities are unique (i.e. economic entities, including companies and even authorities possess a unique public VAT identifier in EU). For the insured persons, we have to avoid using public identifiers in the unencrypted section of the record. They are natural persons whose privacy has to be protected. Even the fact, that someone is or was insured at all is not for public. Therefore, only the concerned actors (e.g. the PII and the insured person) are allowed to recognize if someone’s data is in the database. The use of relation (employment) identifier shall provide an appropriate solution. The competent pension insurance can generate this ID when the employment is initiated and will share only with the employer and the (insured) employee.

The data entries can be classified into two types. One type is when the registrar (e.g. employer) notify the competent pension insurance about a fact related to the social insurance (e.g. salary of a given month) that the PII has to register. The other type of entries is that the pension insurance institute writes into the database to certify that a fact is registered, legally recognized and certified, or the contrary the registration of a fact is rejected. These entries are for the insured person for later use. On this way, the people have access to legally certified data about all their career that need for the calculation of the amount of their pension. The addressee of the first type of records are the competent pension insurances and the second type are the employees. Therefore, at the first case the pension insurance has to decrypt the encrypted fields of the record, and the employee at the second case. If we suppose the use of public key infrastructure, in the first case the encryption has to be done by the public key of the PII, and in the second case the public key of the employee (insured person). It is important to note that these are encryption keys that have to be different from those keys used for digital signature. The addressees, the PIIs and their customers (insured persons) will recognize the encrypted part of their records using the private pair of their own key. This is the only way to access the confidential information.

Now we can sketch out the record structure:

1. entry (transaction) ID #trid
2. previous transaction (to certify, discard, alter) #prevtrid
3. date/time of entry
4. data source id (e.g. employer) #emp
5. competent pension insurance institute #pii
6. relation (employment) identifier #cust
7. identifier of the public encryption key #key
8. encrypted part of the record

a.????data about the social insurance (substantial information) #data

b.????qualified signature of the data source performed on the previous field

(#data)

c.????qualified time stamp for #data and the signature above

9.????qualified signature of the data source performed on the whole record

10.? qualified time stamp for the whole record

The nine unencrypted fields are open data, available to anyone. The entry ID is a reference to the record. If the transaction is modifying the state of a previous one, #prevtrid is there to provide the link. Even if someone cannot decrypt the encrypted part, he will know that this transaction could change the one referred by this field. It gives a possibility to check whether the state of a transaction has been modified in a later time by searching the transaction ID in field #prevtrid. Date and time of the entry help to filter the database for a shorter period. The data source ID identifies the entry source and allows to check whether the signature in field nine is belonging to that entity. Using date/time and #emp also enables to filter to a monthly social security report of an employee. The #pii filed holds the identifier of the pension insurance institute who is responsible to register the encrypted data of field eight. The #cust field refers the employee through the relation (or employment) identifier. If the encryption key identifier of #key is belonging to the PII, then it is a data report to register by the employer or other data supplier. If belonging to the employee then this is a certified confirmation of the PII that the data is accepted and registered. In the latter case the data source must be a PII. Besides a company the data source can be a health care provider, authority or other actor providing relevant information. If the competent PII has more identifier assigned to a person, the data source can refer to any of her identifiers especially as the reported data (e.g. the birth of a child) sometimes does not relate to a single employment. The public part of the encryption key also identifies the addressee, but in such a system an independently generated id is more appropriate.

The encrypted field No. 8 stores the substantial social security information of the record and the signature and time stamp according to eIDAS. The encryption key is referred by the field #key. When this field is decrypted by the PII or the employee, the transactions details and the belonging certificaton signature and the time stamp will be recovered. This signature is recoverable only by the addressee holding the private pair of the encryption key (the decryption key). This is why we need a signature and time stamp for the open data of the record (this is why the whole record is undeniable for the data source). Field No. 9 and 10 certifies that the data source referred by #emp was the real data source to anyone with no possession of the decryption key. It is worth to note that the encryption/decryption key pair is not regulated by eIDAS, but can be based on the same technical background (i.e. RSA, ECC, or their hybrid crypto system with a symmetric crypto method, like AES). The social security records contain nearly the same data month by month, so it is useful to concatenate the three records before encryption. The avalanche effect of the hash function used by the electronic signature method gives very different data when the data to be signed barely changing. This makes the input of the encryption function volatile and so enlarging the message space of the crypto system. This makes the cryptography less vulnerable against attacks. This system ensures that any protected data can be recovered only by the competent PII and the insured person.

This record structure with the signatures, time stamps and decryption methods meets the requirements previously set up about the data access and protection issues of a single pension insurance registry.

Who rules the database?

Let’s define the database administrator as an actor who grants and revoke the access rights. Certainly, all pension insurance institutes in the EU must possess the read and write access regarding their registered data. According to the suggested method described above, these organizations or the administrator are limited to enter new data just in their own name, they are not able to read or alter the other’s encrypted data. They cannot violate each other’s rights. Moreover, the qualified electronic time stamp, which is released by an external trusted service provider, prevents them to alter the data stored even in their own records. This protection is on record level, so if someone has the right to delete a record this operation shall not violate the integrity rules of other records or the rules of the entire database at least the way we defined it so far. The access rights of the employers and the insured people can be controlled by the competent PII, but ultimately the rights of the cooperating PIIs has to be ruled by the administrator, and it is a big issue to supervise such an actor. Let’s try to set up a system without this controversial role.

The basic requirements are

1. the integrity rules shall protect the entire database against retrospective modifications,
2. the system shall be under the physical and logical control of the pensions insurance institutes on the way that each pension insurance institute is able to exercise its rights without the necessity to cooperate with any other actor (e.g. other PII or administrator),
3. there shall be a method to reach consensus between the pension insurance institutes about the current valid database; without a central authority, this must be a decentralized consensus method.

The first requirement can be satisfied by the system of chained hash-codes and the second one by operating a copy of the database by each PII. It follows that we need a synchronization protocol that guarantees that after any sequence of changes in the different copies of the database the PIIs shall agree which version is to be accepted as the single valid version. Thereafter, all operators (PIIs) will use only that version. These are the basic conditions of the blockchain systems. The systems of the PIIs operating the copies of the database are the nodes. These nodes are in peer-to-peer connection, on technical and legal aspects they can identify each other on a trusted way, using electronic signatures according to eIDAS. We do not suppose that all nodes comply with the rules of the system (the protocol), but we do suppose that the majority of them are trustworthy. Nodes are not obliged to use a particular software, or the nodes have no way of checking what software another node is using. The blockchain protocol ensures that the nodes are able to determine whether a node violated the rules just by examining its broadcasted data. If it happens, the received data will be rejected and will not be included into the next block. If this cheater generates a new block the entire block will be rejected by the trusty nodes.

Data supply into the system

Data suppliers (e.g. employers) upload data to the system by a client software of the blockchain. Clients try to send their transactions (new data records) to as many nodes as they can connect to. Since it is a blockchain, no one can control what kind of client software assembled the record, but all nodes shall control if the record matches the protocol (e.g. record structure and if the signature is belonging to the sender). The nodes collect the transactions to create valid blocks (see https://en.wikipedia.org/wiki/Blockchain). The first who succeed broadcasts the new block to the others. They immediately control if the block and all the included transaction fits to the protocol. If yes, they accept otherwise reject. If more nodes are successful at the same time (before the other broadcasts its block), then two different version will spread over the network. One part of the nodes will use the first, the other part the second version. The blockchain is forked. This is a case we need the decentralized consensus to select one. First the blocks shall work with the valid block they received first. Both branches continue to grow, but the one that was accepted by more nodes will grow faster. There is a rule in the protocol that a node shall use the block that has the most ancestor (the longest one) to try to build a new. The branch that is accepted by the majority of nodes will grow faster because the majority has more processor power than the minority, therefore the other will be dropped by the rest of the nodes. A detailed logical and technical analysis has to be performed to define the attributes of the system. The block size, the method to prove the right to create a block and lots of other parameters of implementation is to be defined depending on the result.

Confirmation of the reported pension insurance data

The pension eligibility data of the records are accessible only for the competent PII, because the data source (e.g. employer) encrypted this part of the record by its public encryption key and only this PII possesses the belonging private decryption key. After decrypting, the pension insurance institute checks if the open data is in the requested form, the electronic signature is valid and belongs to the data source, the e-time stamp does not precede the last day of the employment reporting period, the insured person (employee) belongs to the relation (employment) identifier given in the unencrypted part of the record. The substantial social security data shall also be checked if they comply with the legal background. There can be a validity condition that cannot be checked at the time of the data supply, but later its value can change to true. Such a case is for example when for the valid pension eligibility, the social security contribution must be paid beside the monthly report. A PII will confirm the transaction if it can do it according to its rules. Blockchain records cannot be amended later, so confirmation must be done in a new record. The insured person needs the confirmed data in authenticated form when later she requests pension. Therefore, the confirmation record has to contain all data of the original report and the official statement of the PII that it is registered as a valid eligibility record. The PII gives its qualified electronic signature and time stamp. Then the data to be protected shall be encrypted by the public encryption key of the customer. The transaction ID of the previous transaction (#prevtrid) shall refer the previous transaction (the report of the employer) and at last the whole record is to be signed and time stamped.

If a record has to be deleted, it will be added as a new transaction, referencing the original as the previous in #prevtrid and the fact that that one is to be considered as deleted (discarded). This type of record has no encrypted part, so everybody can see what transaction is discarded, but of course cannot access the encrypted part of the original (except the one possessing the decryption key). Now we have a common registry of the European pension insurances. But how can a customer recognize her data in such a big blockchain? It makes sense to provide an electronic service for the insured persons (customers) that collects their own records, enabling them to access and download the encrypted pension insurance data.

How to use the system?

The main reason to propose this blockchain system is to join the fragmented registries into a single, secure, legal proof source of pension eligibility data. This way the insured people can access all of their relevant data to calculate the amount of the pension. The proposed system, while satisfying the requirements, is a complicated decentralized blockchain database, that identifies the customers on several identifiers, containing encrypted data that needs encryption keys to be accessed. The use of this system is hardly easier than contacting each competent pension insurance institutes that are registering the relevant career data. We need a public web service or a simple client software to solve the problem. This service can be provided by any PII or a third party. There is no reason to restrict the access to read the blockchain, the unencrypted fields of the records are public data, the encrypted part is protected.

The system is collecting pension eligibility data. Such data is related for example to employment, and the employment is related to an employer and an employee. The employer has a public EU VAT identifier which is unique and accessible to everyone. But we wanted to avoid the use of a public identifier of a natural person. This is why the employer has to request an employment (or relation) identifier (to be stored in field #cust) from the competent pension insurance institute. All records that shall be reported to the system about this employment will refer this ID. This request can be completely automatic when the new employment is reported. The PII generates the ID (or can use an existing one if the employee is already registered depending on the system rules) and share this and the encryption key with the employer. Note, that the decryption part of this key pair is known only by this PII, but the encrypting part is not to be protected (it is not for signature or decryption). The PII also has to share the employment identifier with the employee. At the time of the registration of the new employment the pension insurance has to generate a new encryption key pair to make the protected information accessible to the employee only. The decryption part can be shared with the employee through a qualified trusted service, but is also stored by the PII. The PII can provide an electronic service where the insured person identifies itself on a trusted way (e.g. using an electronic identity card) and the decryption process is made on the server side. However, the access to the key also has to be provided for the customer, even in this case.

Now let’s take a customer who has no records and reliable memory about his employment career history, but is able to identify himself on a traditional or electronic way at the pension institute. He needs all the relation (employment) identifiers to locate all his data. This is what for an average citizen is most probably missing. Let’s suppose he has no any data about his career! This is why it’s worth to let this customer to make any PII, who is able to identify him, be authorized to request all available relation (employment) identifiers from all pension insurance institutes. Based on these IDs he can locate and download all records stored about him however he can’t decrypt the encrypted parts of the records, but can identify all PIIs that confirmed pension eligibility data about him. Now he can contact every PIIs, identify himself using an electronic service or personally and get access to his decryption keys of each relations (employments). Now he can decrypt all substantial eligibility data signed according to EU regulation eIDAS by the responsible pension insurances. He cannot decrypt the records sent by a third party (e.g. employer or other authority), because these records are encrypted by the key of the competent PII, but if these records were confirmed by the PII, he can read all information in the confirmation record that refers the transaction as previous (in field #prevtrid). If a transaction has no confirmation, he can contact the PII to clarify the cause.

?

Conclusion

The insured person is served all her pension eligibility data in a legal proof form solely with the use of this system. Her personal data can be read only by the competent pension institute who is responsible to register these data anyway. The substantial part of the records can comply to the legal system of the country of employment. There is no central operator or authority to control the system. The participating PIIs (and member states) sovereignty is not affected. There is no authority to limit anyone. Participants are peer to peer. They can cease their cooperation with the system any time they want. This makes no harm to the others remaining in the system. The records already stored in the blockchain remains available as no backward modification is possible. The decryption keys will also work further even if the party who generated them leaves. Legislation about the social security system is not needed as the legal proofness of the records are similar to those signed on paper.

The use of the system requires little additional effort. All data sources send practically the same data to the same pension insurance now. The only extra task is the application of the employment identifier and the encryption. The use of electronic trust will be sooner or later mandatory according to eIDAS regardless of this system. Bureaucracy will not grow in registration of new records but will significantly reduce when applying for a pension. Those citizens of EU who take advantage of the free movement of labor get an instrument to register their pension eligibility which grants legal proofness. This would be the first cooperation to operate a digital system that does not create central supervisory roles, does not require central management or authority and does not reduce the participants’ sovereignty. This method of peer to peer cooperation between member states would be useful in taxation, in fraud analytics and other areas of public administration where otherwise excessive amount of sensitive data exchange would be necessary.