WO2015048859A1 - System and a method for validating an identification token - Google Patents

Abstract

An Identification Device (10) for providing validation information comprising: a Token (11) and a Validator (20); wherein the display (17) is adapted to display, during an Operational Phase, a first security code (15), referred to as the Indicator-of- Clearance code or loC code (15), indicating the Clearance Status (46) of the Token, whereby the first security code (15) is generated by an indicator-of- Clearance Function (23), such as a digital signature or hash function, programmed on the processor unit (21 ) based an the Clearance Status (46) and the Validator Clock (28).

Description

System and a method for validating an identification Token

Technical field

The present invention relates to the field of identity fraud protection and more specifically to a system and a method for validating the validity of the identification data displayed on and/or stored in an electronic identification Token, and thus determining if clearance can be given to the Token while preventing fraudulent use.

Background art

Electronic identification Tokens, such as e-identification (e-ID) cards, security badges or e-passports, are commonly used for security and identification purposes of the owner _«x>Cthe Token. The owner of the Token, referred to hereinafter as the Owner, may include a person or an object carrying a Token and being uniquely identified by the information stored or displayed in the Token. Such electronic identification Tokens, referred to hereinafter as Tokens, may include an electronic chip having a memory adapted to store Identification Data (ID) to uniquely identify the Token Owner. For example such Identification Data may include for a person as Owner the name of the Owner, national ID number, a picture, date of birth, nationality, official employee number, education degree, security clearance level, membership contract number, home address, and other related Identification Data. Examples for an object as Owner may include its serial number, licence plate number of a car, insurance contract number, ID number of the company who produced the object and other related Identification Data. Furthermore, the Token may be provided with a communication interface enabling the Token to interact with an electronic authentication and validation system. The communication interface may be used to perform an electronic identification of the Token Owner and authentication of the Identification Data stored therein. Since electronic identification and authentication of the Token is not always possible, a subset of the Identification Data may be made visible on a Token location. For example the Token may include on a visible location the photo of the Owner along with his name and home address as a printed overlay on the Token.

Due to the value of the Identification Data, identification Tokens have become a major target of fraudulent attacks. For example, an authentic Token of a valid Owner may be used in a fraudulent way by replacing the visible Identification Data displayed on the Token by falsified Identification Data of a false Owner. Furthermore, a fraudulent Token may be manufactured containing falsified Identification Data. In a further example, an authentic Token may be used in an invalid security clearance situation whereby a Token Owner having a predetermined Clearance Status may use his Token to gain access to a part of a building that he is not authorised to enter. Tokens that are falsified, which for example means not authentic, or that are authentic but used in an unauthorised manner, are all invalid Tokens- and will be referred to as such.

In order to prevent such attacks, a range of known security measures have been implemented in the state of the art. For example, in order to prevent falsification of the visible information on the Token, the Token may be provided with a set of visible security items such as holograms, special background prints and special colour dyes.

However, these visible security measures have shown to be relatively ineffective to prevent fraudulent use of a Token. Therefore, recognizing an invalid Token by a visible inspection using the visible security items may become extremely difficuft or burdensome especially in the case where a large number of Tokens need to be validated and thus also authenticated.

To overcome the issues related to the visible security measures, validating a Token may be performed by directly accessing the Identification Data stored in the memory of the Token. For example, this may involve approaching the Token Owner and reading out electronically the Identification Data. However, such an approach may be difficult to implement in the case where a larger number of Tokens need to be validated, for example, when desiring to verify the Tokens of a crowd of people working in a building or the Tokens of cars driving around a city.

US20070013610 presents an apparatus and a technique for allowing an electronic badge to establish a wireless online network with a fixed wireless transceiver mounted in a secure facility and to display information received through the wireless network from the wireless transceiver that is relevant to the secure facility. The apparatus requires that the security badge maintains a continuous wireless connection with the transceiver, which wireless connection is realised using a short range radio frequency. However, a disadvantage of this solution is that the maintenance of such wireless connection requires relatively complicated networks and electronic badges. This is because, in order for the system to work effectively, numerous fixed wireless transceivers and relatively strong batteries in the electronic badges are required to maintain a continuous online connection and sufficient autonomy throughout the building, compound or surroundings where the system is supposed to work. A further disadvantage of this solution, is that validation of the security badge may only be performed while the badge is connected to the wireless network. Therefore, in the case where the network is not available, or the wireless connection is interrupted such a validation procedure cannot be carried out. Moreover, in the case where the invalid badge is not arranged to be connected to the wireless connection once present in a building area, the security facility may remain unaware of the presence of such an invalid badge.

Therefore there remains a need for a validation, and thus authentication, procedure which may be carried out even where the Token is not connected to a security facility.

Disclosure of the invention

It is an aim of the present invention to provide a system capable for continuously validating, and thus also authenticating, a Token or a number of Tokens and the information stored therein, in an easy and quick way.

This aim is achieved according to the invention with the

Identification Device, comprising a Token with a Validator, showing the technical characteristics of the first independent claim.

According to embodiments of the present invention the use of an Identification Device arranged for displaying continuously during an Operational Phase an Indicator-of-Clearance code (loC), which is related to the Clearance Status, i.e. a status indicating that the Token Owner is allowed to perform a valid action or obtain a valid status, of the Token Owner, and, more preferably, a Proof-of-Trust code (PoT), which is related to the authenticity of the loC code and other information displayed on the Identification Device, may allow a validation, and thus authentication, procedure to be implemented that successfully prevents fraudulent attacks in a low complexity and cost effective manner.

According to embodiments of the present invention a Centralised System may be provided, whiqh, may belong to or arranged to be connected to a Trust Authority, such as a governmental or a private organisation. The Centralised System may be arranged to interact with the Identification Device and transfer secure information through a Connector device, which information may be used during an authentication procedure during an Initialisation Phase. By using the Connector device to transfer information between the Centralised System and the Validator device, an additional checkpoint may be implemented. The Connector may be arranged to check the authenticity of the Validator before transferring Data from the Centralised Authority, thereby preventing a falsified Validator from accessing the security information transferred.

Furthermore, a Proof-of-Trust System may be implemented according to embodiments of the present invention, which system in addition to the Identification Device and the Centralised System, may be further provided with a Controller device. In this case the Controller may be an independent device, which may be used to monitor, and thus validate, the data displayed on the Validator Display during the Operational Phase, such as the loC and the PoT codes. As a result, an additional layer of security is added to the Proof-of- Trust system, which may prevent the use of invalid Tokens in a secure environment. An additional advantage of using a Controller device is that the validity of a large number of Tokens may be carried out without the need for approaching the individual Tokens.

It is another aim of the present invention to provide a method. This aim is achieved according to the invention with a method for validating the information displayed on the Identification Device comprising the steps of:

initialising the Validator comprising the steps of: presenting a Token containing information of a person or object to the Validator, such information comprising Identification Data comprising a first subset representing Clearance Data and a second subset representing Trust Data, which Identification Data uniquely identifies the Owner; connecting the Token to the Validator through the Validator communication means, thereby allowing the Validator to access the information stored in the memory of the Token; connecting the Validator to a Connector of a Centralized System through the Validator communication means; transferring data between the Validator and the Centralized System during an Initialisation Phase through the Connector, such data comprising a clock synchronization signal for synchronizing the Validator clock to a Centralized system clock of the Centralized System; and Clearance Rules specifying whether the Token based on the Clearance Data stored in the Token, can be given a specific Clearance Status that indicates that the object or person, i.e. the Owner, is allowed to perform a valid action or obtain a valid status; and

- operating the Validator during an Operational Phase for validating the information in a Token comprising the steps of: displaying the Trust Data on the Validator display; generating a first security code, referred to as the Indicator-of-Clearance code, indicating the Clearance Status of the Token, whereby the first security code is generated by an Indicator-of- Clearance Function, such as a digital signature or hash function, programmed on the processor unit based on the Clearance Status and the Validator Clock; and, generating a second security code, referred to as the Proof-of-Trust code, generated by a MAC function programmed on the processor unit based on the Trust Data displayed on the Validator display and the first security code; and further additionally displaying on the display of the Validator the first security code and the second security code. Brief description of the drawings

The invention will be further elucidated by means of the following description and the appended figures.

Figure 1 shows an Identification Device according to embodiments of the present invention.

Figure 2 presents a Validator Device for the validation and thus also the authentication of the information stored in a Token.

Figure 3 shows a validation procedure with the data and calculation flow for validating informatjorj stored in a Token and calculating the loC and PoT codes.

Figure 4 shows a further validation procedure with the data and calculation flow for validating information stored in a Token and calculating the loC and PoT codes.

Figure 5 shows a Controller device according to embodiments of the present invention. ' ^"

Figure 6 presents a validation procedure with the data and calculation flow for validating the information displayed on the Validator display using a Controller device.

Figure 7 presents a further validation procedure with the data and calculation flow for validating the information displayed on the Validator display using a Controller device.

Modes for carrying out the invention Protecting Identification Data against identity fraud has become a major challenge for governmental and private organisations alike. However, an even greater challenge is authenticating and/or validating that the Token and the Information Data stored therein are authentic, valid and have been issued by a Trust Authority. A Trust Authority may be a private or a governmental organisation having the right to issue such a Token, for example a company may issue security badges to the employees of the company. A Token may be a badge, an e-passport, an identity card, or any other means used for identification purposes. To validate the validity of the Token, a validation procedure may be performed at a designated checkpoint. Such an inspection may involve a visual inspection of the data printed on the Token, which may further be combined with an electronic inspection of the Identification Data stored therein. The Identification Data may be stored with a Secure Element of the Token specified by the Trust Authority, which Secure Element may be a predetermined location of the memory of the Token used explicitly for storing Identification Data or a separate component in the chip of the Token. However, it has been found that such measures cannot guarantee the effective detection of invalid Tokens, especially when somebody succeeds in bypassing the electronic inspection at an entry checkpoint or if entry checkpoints cannot be physically impfemented.

Therefore, according to embodiments of the present invention, an Identification Device may be provided adapted to continuously validate the validity of a Token or a number of Tokens and the information stored therein in a quick and a cost effective manner.

Although the workings of the_^ present invention will be described with reference to the identification Token being configured as a security badge, this should be understood as a non limiting example since other types of identification Tokens may also be authenticated and validated using the present invention. Such examples may include but not limited to an e- identification card, an e-passport, or an identification e-tag placed on an object.

The Tokens and their Owners can be confined to a small closed space or can be distributed in a large geographical area, even across countries. For example a validation procedure may be carried out on the Tokens of each construction worker on a 20 km cross border road construction site, where the Tokens must be registered on a specific time registration system and be enlisted with a social security organization. A further example of a validation procedure may involve the registration of the Tokens of all cars used on the roads in a specific geographical area on a specific day.

A set of Tokens that are all individually authenticated by the Trust Authority and that meet the clearance criteria set by the Trust Authority so that they are considered as valid for these clearance criteria, will be referred to hereinafter as a Set-of-Valid-Tokens. Through the present invention, the Trust Authority is able to provide to any party a continuously visible authentication of each Token that is a member of a Set-of-Valid-Tokens. Complementary, the Trust Authority will also immediately visibly identify to any party a Token that is not a member of a Set-of-Valid-Tokens.

To ensure that the data in the Token is not corrupted, the Token and the information stored therein may be digitally signed by the Trust Authority, for example a governmental or a private organisation.

According to embodiments of the present invention, Identification Devices may be provided, which enables a Trust Authority to validate the validity of a large number of Tokens and the authenticity of the Identification Data stored therein.

The Identification Device may be arranged for authenticating and validating the information stored in a Token issued by a Trust Authority. The Token may be provided with a memory for storing Identification Data that uniquely identifies the identity of the Owner of the Token. The Trust Authority may encode the Identification Data in the Token. A first subset of the Identification Data, referred to hereinafter as the Clearance Data, may indicate that the Owner of the Token has the clearance of the Trust Authority to perform a certain action or to obtain a certain status so that the Trust Authority for example will consider the Token as "valid" for this action or this status. A preferred second subset of the Identification Data is referred to hereinafter as the Trust Data.^■ ~

The identification device may further comprise a Validator device for validating the authenticity and/or validity of the Token. The Validator may comprise a display adapted to display the Trust Data, a subset of the Identification Data stored in the Token. The display can be a fully electronic display or a combination of both an electronic display part and a printed display part. The Validator may further comprise a processor unit, a Validator clock and Validator communication means for interacting with the Token and with a Connector of a Centralized System. The Validator may further be adapted to transfer data during an Initialisation Phase between the Centralized System and the Validator through the Connector. Such data may comprise for example, a clock synchronization signal for synchronizing the Validator clock to a centralized system clock of the Centralized System, and Clearance Rules specifying whether the Token, based on the Clearance Data stored in the Token, can be given a specific Clearance Status that indicates that the Owner is allowed to perform a valid action or obtain a valid status. For example, the Clearance Rules enable the processor unit to calculate a Clearance Status with a Clearance Function programmed on the processor based on the Clearance Data obtained from the Tokefl and the Clearance Rules for example obtained from the Centralized System. The display of the Validator may further be adapted to display, during an Operational Phase for example in addition to the Trust Data, a first security code, referred to as the Indicator-of-Clearance (loC) code, indicating the Clearance Status of the Token generated by an Indicator-of-Clearance Function, such as a hash function or a digital signature, programmed on the processor unit for example based on the Clearance Status and the Validator Clock, for example through an incremental status representing the Validator Clock; for example the time itself, and preferably, a second security code, referred to as the Proof-of-Trust (PoT) code, generated by a Message Authentication Code function or MAC function programmed on the processor unit based on the data displayed on the Validator display, namely the displayed Trust Data and the Displayed loC code. This set of data used as input to the MAC function for the generation of the second code is referred to hereinafter as the MAC Data.

By using the Identification Device of the present invention, the loC and the preferred PoT codes of the authentication and validation procedure are continuously displayed on the Validator display and will change in function of the Validator Clock, for example at each incremental status of the Validator Clock. As the Clearance Status and the incremental status of the Validator Clock are preferably the same orvall Identification Devices of Tokens of a Set-of-Valid-Tokens, the loC code on all these Identification Devices will change to the same new loC code at each incremental status of the Validator Clock. Identification Devices of Tokens that are not part of a Set-of-Valid- Tokens will continuously have different loC codes, except by chance. Therefore, the loC code already provides a first check on whether a Token is part of a Set-of-Valid-Tokens and this without always having to be connected to a network.

The continuous display of the loC and the preferred PoT codes may allow for the validation procedure^' of the Token to be performed in a number of ways. For example, validation of the Token may be verified by a pure visual inspection of the information displayed on the Validator display at any point in time. Therefore, the validation_* of a Token can be performed by a person or a system, without approaching the Token to access the electronic information stored therein. Moreover, the validation of the Token does not require the Validator to be continuously connected via a network to the Centralised System of the Trust Authority.

According to embodiments of the present invention the Centralised System, may be provided with a Connector device and a Centralised System clock. The Connector device may be adapted to interact, preferably securely interact, with the Validator communication interface to transfer data during an Initialisation "Pfiase between the Centralized System and the Validator, such data comprising a clock synchronization signal for synchronizing the Validator clock to the Centralized System clock, and Clearance Rules specifying whether the Token, based on the the Clearance Data stored in the Token, can be given a specific Clearance Status that indicates that the Owner is allowed to perform an action or obtain a valid status. The Centralised System may further be arranged to have access to a Secure Element of the Trust Authority on the Token or the Validator, which may contain data information used during the authentication of the Token or the Validator.

By using a Connector for transferring information between the Centralised System and the Validator device, an additional check point may be implemented. The Connector may be arranged to check the authenticity of the Secure Element of the Token and the Validator before transferring Data from the Centralised System. As a result unauthorised access of this information or replication of such information may be prevented.

According to embodiments of the present invention, a Proof -of - Trust-System (PoTS) may further be provided. The Proof-of-T rust-System may comprise at least one Identification Device according to the present invention, which is arranged to cooperate, or being connected during an Initialisation Phase to the Centralised System according to the present invention. The PoTS system and the devices used thereof may be controlled by the Trust Authority. Therefore, an attempt to falsify a device of the PoTS system would not be successful because a falsified device may not succeed in transferring the required data, which enable communication with the other devices in the System. As a result, a falsified device may become easily detectable in a PoTS system. *

According to embodiments of the present invention the data transferred during an Initialisation Phase of the Validator between the Centralized System and the Validator may comprise a set of Time Rules. The Time Rules enable the processor unit to calculate with a Time Function programmed on the processor, a set of time intervals, referred to hereinafter as a Set-of-Time-Points. The Set-of-Time-Points are provided as input to the Indicator-of-Clearance Function such that respective Indicator-of-Clearance codes are generated for each of the time intervals.

By using the Time Rules, the loC code may be generated at specific time intervals with respect to the Validator clock, which Validator clock is synchronised with the Central System clock and therefore with all Validator Clocks of all Validators used for a Set-of-Valid-Tokens. The Time Rules may only be known to the Trust Authority and may be changed by the Trust Authority for a next session when the P oof-of-Trust System is activated. Therefore, an invalid Token not having access to the Time Rules would not be able to generate the loC code at the specified intervals. The loC codes generated at each time interval specified by the Time Rules may be arranged to synchronously switch the loC code on all the Validators to an unpredictable new loC code. As a result, a quick visual inspection and a comparison with the loC code(s) generated by a valid Token would be sufficient to identify an invalid Token out of a number of Tokens, and thus validate the Token. For example a fraudulent party who cannot calculate the next loC, can only copy that loC once it is visible on the VaUdators of Tokens from the Set-of-Valid- Tokens. This party must then, at each point in time of the Set-of-Time-Points copy this new loC and get it on the display of his fake Validator. This type of fraud is complex to implement, unreliable at all time points and will always have a time delay that is detectable by independent observer

The Time Rules may further define a time limit period, at which an Operational Phase of the Validator ends, for example a session of an Operational Phase of the Validators ends. During the Operational phase the Validator is arranged to generate continuously authentication codes, such as the loC and PoT codes. At the expiry of the Operational Phase the Validator stops generating Indicator-of-Clearance codes and/or Proof-of-Trust codes until a new Initialisation Phase occurs. The Time Rules for example may identify that the Operational phase of a Validator Device may end at the end of a specified working day.

During the Operational phase the Validator may continuously generate authentication codes in an autonomous manner. Therefore, in contrast to solutions in the prior art, the Identification Device or the Centralised System, or the Proof-of-Trust System may not be required to be connected during the Operational Phase to a wireless or wired network for transferring data or instructions between the components of the system. This may have as an effect that the cost and complexity of such a continuous authentication procedure may greatly be simplified.

During the period specified by the Time Rules the Indicator-of- Clearance codes generated by the Indicator-of-Clearance Function may be identical on all the displays of all the Validators with Tokens that are valid, namely with the same Clearance Status. This feature may enable identification of an invalid Token by Owners of authentic Tokens located in the proximity of the invalid Token. As a result, a social control scheme may be implemented. This social control scheme may rely on independent observers, for example, Token Owners working in the same security clearance area, to notice that the loC code displayed on a Validator Connected to an invalid Token does not correspond to the one displayed on the Validators of the rest of the Token Owners, and report any abnormality to a responsible authority.

According embodiments of the present invention, the processor unit of the Validator may be adapted to select an Animated Indicator-of- Clearance Transition (loC Transition) from a predetermined database. The database may comprise Animated Indicator-of-Clearance Transitions to be displayed on the display of the Validator prior to the displaying of a new Indicator-of-Clearance code. The displayed Animated Indicator-of-Clearance Transitions are preferably identical and displayed synchronously on all Validators linked to a Token of a Set-of-Valid-Tokens. Thereto, the processor unit of each Validator is for example adapted so that each potential Indicator- of-Clearance code has a corresponding uniquely different Animated Indicator- of-Clearance Transition codified in a database of Animated Indicator-of- Clearance Transitions in the Validator and to be displayed on the display of the Validator prior to showing the new corresponding Indicator-of-Clearance code, and wherein the Animated Indicator-of-Clearance Transition database is identical for all Validators used for Tokens that are part of or want to be part of the Set-of-Valid-Tokens. For example, the Indicator-of-Clearance Function might have a database with different 5-seconds animations for each potential loC code. A different database might exist for each time point of the Set-of- Time-Points. This animation might include coloured blocks and symbols that might move over the display of the Validator.

Because the loC code, the fndicator-of-Clearance Function and the Animated loC Transition databases may be the same on every Validator of a Set-of-Valid-Tokens, the same Animated loC Transition preceding every time point of the Set-of-Time-Points may be shown on all Validator displays. When the animation for example covers the whole display of the Validator, the social control scheme is even more visible from a remote distance. Therefore, use of an invalid Token may become even more difficult as a fraudulent party would have to mimic an unpredictable animation on his own fake Validator synchronously with all Validators of the Set-of-Valid-Tokens.

According to an embodiment of the present invention, the data transferred during the Initialisation Phase between the Centralized System and the Validator through the Connector may comprise a set of Indicator Rules used by the Indicator-of-Clearance Function as additional input to generate the Indicator-of-Clearance code.

The Indicator Rules can be a set of confidential rules determined by the Centralised System, which are for example only valid for the predefined period, which period is defined by the Time Rules, e.g. a predefined period that ends at the end of a working day. The Indicator Rules may be identical on all Validators for Tokens that are or want to be member of the Set- of-Valid-Tokens, thereby ensuring that the loC is calculated in the same manner on all these Validators. The Indicator Rules may for example be in the form of parameters further defining the Indicator-of-Clearance function.

In an alternative embodiment, the Indicator Rules may be an independent set of Rules transferred -by the Trust Authority in a strictly confidential manner during the Initialisation Phase from the Centralised System through a Connector to the Validator.

The integration of the Indicator Rules with the Indicator-of- Clearance Function can make the security of the system more robust. The Trust Authority may for example consider publishing the Indicator-of-Clearance Function while maintaining the Indicator Rules secret. In the case, where accidentally one instance of the Indicator Rules become public, it would be sufficient for the Trust Authority to generate a new set of Indicator Rules for a new period to ensure that the Proof-of-Trust System is again reliable.

By using the Indicator Rules, the falsification of the loC and PoT codes may be prevented. Therefore, such Rules may further increase the security and prevent the use of invalid. Tokens in a secure environment.

According to further embodiments of the present invention, the data being transferred during an Initialisation Phase between the Centralized System and the Validator may further comprise a set of Trust Rules used as additional input by the MAC function to generate the Proof-of-Trust code. The Trust Rules can be a set of confidential rules determined by the Centralised System, which are for example only valid fdr a predefined period of the Set-of- Time-Points, e.g. a predefined period that ends at the end of a working day. The Proof-of-Trust Function might include cryptographic MAC functions with a secret key in which case the Trust Rules might include a secret key for those cryptographic MAC functions. The Trust Rules are identical on all Validators for Tokens that are or want to be member of the Set-of-Valid-Tokens, thereby ensuring that the PoT is calculated in the same manner on all these Validators.

The integration of the Trust Rules with the MAC Function can make the security of the system more robust. The Trust Authority can now make the MAC Function public while maintaining the Trust Rules secret. If for some reason one instance of the Trust Rules become public, it is sufficient for the Trust Authority to generate a new set of Trust Rules for a new period to ensure that the Proof-of-Trust System is again reliable.

By using Trust Rules and Indicator Rules that may only be valid for a predetermined amount of time, it is guaranteed that the generation of the loC and PoT codes are practically impossible to be falsified over a longer time frame, for example years. The Validator may further comprise a memory for storing the Clearance Rules, Time Rules, Trust Rules and Indicator Rules. The Clearance Rules, Time Rules, Trust Rules and Indicator Rules may be stored in a specific location in the memory, which is specified by the Trust Authority during issuing the Validator Device.

Therefore, during authentication of the Validator the exact location of the memory where the Clearance Rules, Time Rules, Trust Rules and Indicator Rules are stored may further be used as a security feature.

The Validator can also comprise a memory, for example the same memory as mentioned above, for storing any one or more of the Indicator-of-Clearance Function, the MAC function, and, if present, the Time Function and/or the Clearance Function- According to embodiments of the present disclosure, the Validator communication means may comprise, for example exclusively comprise, wireless communication means during the Initialisation Phase, for example NFC, Bluetooth, mobile telephone networks, etc. The Validator communication means during the Initialisation Phase may also include, for example exclusively include, the use of wired communication means, such as physical contacts, cables, USB, etc.

The use of wireless communication means may enable the

Validator to connect to other devices without the need for a physical connection. The use of wired communication may be used for transferring the data from the Centralised System to establish a more secure connection for transferring data. The use of wired communication between Tokens, Validators, Connectors and the Centralised System during the Initialisation Phase may avoid all the security risks of wireless communication, providing an additional benefit of the Proof-of-Trust-System compared to previous art.

According to embodiments of the present invention, the Token and the Validator may be integrated into a single Identification Device, which will be issued by a Trust Authority. In this configuration, the Token may be adapted to display and generate the displayed Trust Data and the loC and PoT code according to the information received from the Centralised System through the Connector. By integrating the Token and the Validator into a single Identification Device, the cost and complexity may be reduced considerably.

According to embodiments of the present disclosure, the Proof- of-Trust-System may further comprise a Controller for validating the validity and thus also the authenticity of the information displayed on the Identification Device and for verifying if a particular Identification Device is a member of a Set-of-Valid-Tokens. The Controller comprises means for capturing data displayed on an Identification Device, a display, a processor unit, a Controller clock and Controller communication means for securely interacting during an Initialisation Phase with a Connector of the Centralized System. The data captured from the display of an Identification Device includes the displayed Trust Data, the displayed Indicator-of-Clearance code and the displayed Proof- of-Trust code. The Controller contains the same Indicator-of-Clearance Function and MAC Function as the Validators used for Tokens of a Set-of- Valid-Tokens. The Controller is adapted to transfer data from the Centralized System through the Connector during an Initialisation Phase. Such data may comprise the required Clearance Status and a clock synchronization signal for synchronizing the Controller Clock to a Centralized System clock of the centralized system. The processor unit of the Controller is further adapted to generate the required Indicator-of-Clearance code by the Indicator-of- Clearance Function programmed on the Controller processor unit based on the required Clearance Status and the Controller Clock. The required Proof-of- Trust code is generated by the MAG" function programmed on the processor unit based on the displayed loC code and the displayed Trust Data shown on the Validator display of the Identification Device.

If the Validators of the Identification Devices that must be validated, require the use of Indicator Rules, Time Rules, a Time function and/or Trust Rules, then these rules are also present in the data transferred during the Initialisation Phase of the Controller with the Centralized System and/or the Time Function is programmed on the processor unit of the Controller such as to be able to make the processor unit of the Controller adapted to re-generate the loC code and the PoT code which is supposed to be shown on the Validator display. According to further preferred embodiments the processor unit is further provided for comparing the loC code and the PoT code captured from the Validator display with the required loC code and the required Pot code generated by the processor unit of the Controller such as to be able to detect whether the Token is part of the Set-of-Valid-Tokens or not.

The Controller can thus independently control the validity and thus also the authenticity of the loC-code, PoT-code and the Trust Data displayed on any of the Validators. The Controller may be arranged to identify invalid Tokens and/or invalid Valida ors by using information visible on the Validator and without approaching the person or object holding the Validator and Token.

Therefore, by providing a Controller in the Proof-of-Trust system another layer of security is added that guarantees that the Token and the information stored therein are authentic and valid. In the case of an invalid Token, a Controller may detect, possibly even immediately detect, that the information displayed on the Validator is not correct and alert the responsible authority to take appropriate measures.

According to embodiments of the present invention, the processor unit of the Controller may be adapted to display the result of a comparison. The comparison is performed between the Indicator-of-Clearance code and the Proof-of-Trust code generated in the processor unit of the Controller and the loC code and the PoT code displayed on an Identification Device and captured by the Controllec nformation capturing means.

By displaying directly the results of the comparison between the loC and PoT codes, the status of the Identification Device and the authenticity of information displayed therein can be more easily determined as it is visually indicated whether the Identification Device is a member of a Set-of-Valid Tokens or not. Furthermore, by directly displaying the results of the comparison the responsible authority may be able to accelerate the authentication procedure of a large number of Tokens and act promptly to an attempt of using an invalid Token in a secure environment.

According to embodiments of the present invention the means for capturing information of the Controller may comprise a device adapted to optically capture and convert the displayed data, more in particular the displayed Trust Data, the displayed loC code and the displayed PoT code, of the Identification Device to a digital format using an Optical Character Recognition interface. For example, such a device may include a camera connected to a computer that is adapted to convert the image received in a digital format. Examples are surveillance cameras with associated systems, Google Glasses or any other equivalent devices.

By using a Controller having an Optical Character Recognition interface, multiple Tokens may be validated and thus authenticated at once without the need for human intervention and without the need of a wired or wireless electronic connection between the Controller and the Identification Device.

According to embodiments of the present invention a method for validating and thus authenticating the information in a Token may be provided, the method comprising the steps of : initialising the Validator device in an Initialisation Phase comprising the steps of: presenting a Token containing information of a person or object to tRe Validator, such information comprising Identification Data comprising Clearance Data and Trust Data, which Identification Data uniquely identifies the person or object; connecting the Token to the Validator through the Validator communication means, thereby allowing the Validator to access the information stored in the memory of the Token; connecting the Validator to a Connector of a Centralized System through the Validator communication means, transferring, preferably securely, data between the Validator and the Centralized System through the Connector, such data comprising all data applicable to all Tokens of a Set-of-Valid-Tokens, which might include Time Rules, Clearance Rules, Indicator Rules, Trust Rules and a clock synchronizing of the Validator clock with a clock of the Centralized System; and processing the information gathered comprising the steps of: calculating in the processor unit of the Validator the Clearance Status of the Token by applying the Clearance Rules to the Clearance Data of the Token through a Clearance Function; calculating, if applicable, in the processor unit of the Validator the Set-of-Time-Points using a Time Function, having as input the Validator Clock and the Time Rules; then starting an Operational Phase of the Validator comprising the steps of : calculating in the processor unit of the Validator an Indicator-of-Clearance (loC) code using an Indicator-of-Clearance Function, such as a digital signature or hash function, programmed on the processor unit with as input the Clearance 'Status, a specific Time Point of, if applicable, a Set-of-Time-Points and optional Indicator Rules; displaying at each specific Time Point in the display of tjie Validator the Trust Data and the loC code associated with that Time Point; calculating in the processor unit of the Validator a Proof-of-Trust (PoT) code using a Message Authentication Code (MAC) function based on the displayed Trust Data, displayed loC code and optional Trust Rules, and displaying in the display of the Validator together with Trust Data and loC code the PoT code generated by the processor unit.

The method may further comprise the use of a Controller device to validate and thus authenticate the information displayed on the display of the Validators of the Tokens that claim to be part of a Set-of- Valid-Tokens. The Controller contains the same Indicator Function, MAC Function and, if applicable, Time Function as the Validators of the Tokens of the Set-of-Valid- Tokens. The Controller prior to be used for authentication and validation needs to undergo an Initialisation Phase similar to that of the Validator. The Controller may be initialised by connecting the Controller using the communication interface to the Centralised System belonging to the Trust Authority through a Connector in a fully secure and confidential manner. Once the Controller is connected to the Centralised System, the required data may be transferred via the communication link established by the Connector. Such data may comprise but not limited to the same data as used in the Validators of the Tokens that claim to be part of the Set-of-Valid-Tokens, namely a clock synchronization signal for synchronizing the Controller clock to the clock of the Centralized System, the required Clearance Status and, if applicable, the Time Rules, the Indicator Rules and/or the Trust Rules. The Set-of-Time-Points, if applicable, may be further generated based on the synchronised clock and Time Function, wherein the Set-of-Time-Points are identical to the ones used in the Validators of the Tokens that claim to be part of the Set-of-Valid-Tokens. Next, the Operational Phase of the Controller may be started for verifying the validity of Identification Devices by (re)generating the required loC code using the Indicator-of-Clearance Function programmed in the processor unit of the Controller with as input, if applicable, the Set-of-Time-Points, the required Clearance Status and, if applicable, the Indicator Rules. The Controller may comprise capturing means for capturing the information displayed on the Validator display of the Identification Device, and provide the data captured as an input to the processor unit of the Controller, thereby allowing for a direct comparison between the displayed loC of the Validator and the required loC generated by the processor unit of the Controller. The results of the comparison may be displayed on the Controller display. To further confirm that the Data displayed on the Validator display is authentic the Controller may be arranged to generate the required PoT code using the MAC Function with as input the displayed loC code, the Trust Data displayed on the Validator, and, if applicable, the Trust Rules. Once again the required PoT code generated by the processor unit of the Controller may be compared to the PoT code displayed on the Validator and the cofhp^'arison results may be displayed on the display of the Controller. The results from the comparison between the loC codes and PoT codes may further be communicated to the Trust Authority or another security authority, so that action against invalid Tokens can be taken immediately.

General Description

Figure 1 shows an Identification Device 10 according to embodiments of the present invention, which may be used for authenticating and validating the information in a Token 1. The Identification Device 10 presented therein comprises a Validator device 20, which may be an electronic device provided separately by the Trust Authority, which may be configured to cooperate with the Token 11. For example, a Validator 20 may be a badge holder with a card reader adapted to work together with the Token 11 and that is visible worn on the chest of a person. A further example of a Validator 20 may include a display device mounted next to the licence plate of a car or a truck and connected with a device that can electronically read a Token 11 on the dashboard of the car or the truck.

According to embodiments of the present invention, the Token

11 may be provided with a cryptographic digital signature algorithm, referred to as a Secure Element, which may be stored on the Token and adapted not to be copied to the chip of another Token. For example the Secure Element may specify a unique memory location known only to the Trust Authority, where the required data from the Trust Authority may be stored. In a further example, the Secure Element may be an independent electronic component integrated on the electronic chip of the Token. The Secure Element may act as a cryptographic authentication mechanism for the Token to other parties to ensure that only trusted parties have access to the Identification Data 43 stored in the Token. For example, an authentication system at a checkpoint may electronically read the content of the Token, authenticate the Secure Element on the Token according to cryptographic practice and make a distinction between authentic and fraudulent Tokens.

Figure 2 presents a schematic description of a Validator device 20 according to embodiments of the present invention. The Validator 20 may be provided with communication interface 25 for interacting with the Token, which may be a wired or a wireless^" interface. A further communication interface 26 may also be provided for interacting through a Connector 27 with the Centralised System 30 of the Trust Authority, which may also be a wired or wireless communication interface depending on the security requirements. Furthermore, the Validator 20 may further be provided with a processor unit 21 for processing information and a Secure Element 22 provided by the Trust Authority. The processor unit 21 may comprise stored software programs and a memory for storing the input and output data generated. Next to the processor unit 21 , a specific signature or hash function may be stored in a secure and encrypted database 55 and used as a program on the processor unit 21 , which is only known to the Trust Authority and referred to herein after as the Indicator-of-Clearance-Function 23. The Indicator-of-Clearance- Function 23 can be any function that for example transforms multiple input data in a single output result. However, the Indicator-of-Clearance-Function 23 must have at least one feature: the output should not be predictable, or at least not substantially predictable, as defined by cryptographic practice based on previous output results generated by the function and by previous input data during the time period in which the Validator may operate. Examples of such functions are signature functions or hash functions such as SHA- , SHA-2 and SHA-3. To further increase the level of security, a further specific message authentication code (MAC) function 24 according to cryptographic practice may be stored in a secure and encrypted database 55, used as a program on the processor unit 21 and only known to the Trust Authority. The Validator 20 may also be provided with an internal clock 28 for synchronising events and a display 17 for displaying all or part of the Identification Data 43 stored in the Token and the authentication related information generated in the Validator 20. The part or subset of Identification Dala'stored in the Token to be displayed is referred to hereinafter as the Trust Data 45. The Trust Data 45 may be chosen by the Trust Authority issuing the Token, so that the displayed Trust Data 45 is sufficient to uniquely identify the Owner of the Token in a particular security environment. Examples of such displayed Trust Data 45 may be the licence plate number of the car, the first and last name of a person 12, the ID number 3 of a person, and a project code assigned to a person 14.

In the case where a Token 11 claims to be part of a Set-of-Valid- Tokens, a Validator device 20 may be used in combination with this Token 11 so that authentication and validation of the information stored therein can be carried out. The Validator 20 may follow an Initialization Phase to authenticate the Token 11 and collect the data from the Token 11 and from the Centralised System 30. An example of an Initialization Phase of the Validator is shown in Figures 3 and 4, which Initialization Phase is represented by the solid arrows. This initialization phase, hereinafter referred to as the Initialization Phase, may start by presenting the Token 1 to the Validator 20 so that the Validator 20 may access the Secure Element of the Token 11 through the communication interface 25 to authenticate the Token 11. The Validator 20, once communication with the Token has been established, may start reading the Identification Data 43 stored in the Token through the wired or wireless communication interface 25, such Identification Data 43 may further include the Clearance Data 44 and Trust Data 45. The Validator 20, preferably at that time, may further be connected to the Centralised System 30 belonging to the Trust Authority such as a governmental or a private organisation. A Connector device 27 may be used to establish_^such a wired or wireless communication interface 26, to enable the transfer of data between the Validator 20 and the Centralised System 30 through the Connector 27 in a fully secure and confidential manner. The Centralised System 30 may first start to authenticate the Secure Element 22 of the Validator 20 through the Connector 27. The Connector 27 may also contain a Secure Element so that the Trust Authority can verify the authenticity of, i.e. authentidate, a Connector 27 at any point in time. Examples of Connector Devices 27 are contact card readers or proximity badge readers arranged to transfer the data information via the communication link established by the Connector 27 with the Centralised System 30. The data information transferred from the Centralised System 30 to the Validator 20 may comprise a clock synchronization signal for synchronizing the Validator clock 28 to the clock of the Centralized System 31. Through the clock synchronisation signal, all Validators 20 used to verify a Set-of-Valid-Tokens may be synchronized with the same clock of the Centralized Clock 31 of the Trust Authority. Moreover, the Centralized System 30 may transfer different sets of data to the Validator 20, such as Clearance Rules 32 and optionally Time Rules 34, as shown in Figure 4. These sets of data may be identical for all Validators used to verify Tokens that are member or want to become members of the specific Set-of- Valid-Tokens. Next, the Validator may theft apply the Clearance Rules 32 to the Clearance Data 44 of the Token 11 through, for example, a Clearance Function 41 to determine a Clearance Status 46. The Clearance Function may be stored in a secure and encrypted database 55 and used as a program on the processor unit 21. The Clearance Rules 32 may be in the form of criteria imposed by the Centralised System 30 to verify the Clearance Data 44 in a Token and based on which a particular valid Clearance Status 46 of the Token may be determined. For example, the Clearance Rules 32 might stipulate that the Clearance Data 44 of a Token should at least contain one job title from a list of job titles in order to give the Owner of the Token a valid Clearance Status 46 that allows him for example to perform a certain action and/or be in a specific location and/or during a certain amount of time. In specific embodiments of the present disclosure, the Clearance Rules 32 may be transferred to the Validator 20 and the Clearance Status 46 may be generated by the processor unit 21 of the Validator 2/3 using the Clearance Function 41 by applying the Clearance Rules 32 to the Clearance Data 44 stored in the Token. In further embodiments, the Centralised System 30 may generate the Clearance Status 46 by transferring the Clearance Data 44 of the Token 11 to the Centralised System 30 through the Connector 27, and sending the resulting Clearance Status 46 back to the Validator 20 through the Connector 27.

Based on the collected data, the Validator 20 may define a set of time intervals, referred to as Set-of-Time-Points 52, at which the Validator 20 may generate and display authentioatien and validation related information. The Set-of-Time-Points 52 may be determined with a Time Function 51 using as input the Time Rules 34 and the time defined by the internal Validator clock 28. The Time Function may be stored in a secure and encrypted database 55 and used as a program on the processor unit 21. Because the Validator clock 28 and the Time Rules 34 may be identical for all Validators in use for a Token that claims to be part of a specific Set-of-Valid-Tokens, the Set-of-Time-Points 52 may also be equal on all Validators 20. For example, the Times Rules 34 may define that authentication related information must be calculated and displayed every 5 seconds of the current calendar day, for example May 18^th, 2013 according to GMT starting at OhOO 04'. The Set-of-Time-Points 52 is then OhOO 04', OhOO 09', OhOO 14', up to 23h59 59', all during May 18^th, 2013 GMT. In a further example, the Time Rules"34^* may define that authentication related information must be calculated and displayed starting at 18h00 on May 18^th, 2013 GMT and increased with time intervals X whereby X is a set of natural numbers contained in the Time Rules. When X is for example 17, 12, 3, etc. then the Set-of-Time Points are 18h00 00', 18h00 17', 18h00 29', 18h00 32\ etc., all during May 18^th, 2013 GMT.

Once all required data have been transferred between the Validator 20 and the Centralised System 30 and between the Validator 20 and Token 11 , and once the above mentioned tasks are executed, the Initialisation Phase may be closed and the Validator may enter the Operational Phase. An example of the operation phase of the Validator is shown in Figure 3 and Figure 4 and is represented by the dotted arrows. The loC code 15 may then be generated by the Indicator-of-Clearance-Function 23 programmed on the Validator processor unit 21 based on the Clearance Status 46 calculated during the Initialisation Phase and this status of the Validator clock 28 and/or, optionally, a specific time point of the Set-of-Time-Points 52 determined by the status of the Validator clock 28. The loC code 5 may be indicative of the type of Clearance Status 46 assigned to the Token Owner in accordance with the Clearance Rules 32 imposed by the Trust Authority. Because the valid Clearance Status 46, the status of the Validator Clock and the Set-of-Time- Points 52 may be identical for all Validators 20 for a specific Set-of-Valid- Tokens, the loC code 15 may also be identical for all Tokens 11 satisfying a specific set of Clearance Rules 32 during the time interval for which a Set-of- Time-Points 52 exits, thereby facilitating the detection and prevention of invalid Tokens.

The loC code 15 may be displayed on the display 17 of the Validator at the exact specific time point for which it is calculated. The loC 15 is displayed next to the displayed Trust Data 45.

By displaying the loC code 15 that may be identical for all Token

Owners having the same valid security clearance, a social control scheme may be implemented. This scheme may rely on independent observers, for example Token Owners working in the same security clearance area, to notice that the loC code 15 displayed on a Validator 20 linked to an invalid Token does not correspond to the one displayed on the Vajidators 20 of the rest of the Tokens 11 and report any abnormality to a responsible authority. Because the loC codes 15 synchronously switch on all the Validators 20 of the Set-of- Valid- Tokens to an unpredictable new loC code 5 at each time point of the Set-of- Time-Points 52, fraud may be easily detectable at each time point. For example, a fraudulent party who cannot calculate the next loC 15 can only copy that loC 15 once it becomes visible on the Validators 20 of Tokens 11 from the Set-of-Valid-Tokens. This party must then, at each point in time of the Set-of-Time-Points 52 copy this new loC 15 and get it on the display of his fake Validator. Although this type of fraud is possible, it is complex to implement, unreliable at all time points and may always have a time delay that is detectable by an independent observers.

In order to increase further the security measures, an Animated Indicator-of-Clearance Transition may also precede the display of a new loC code. The Validator may then contain for example a database with a different 5-seconds animation for each potential loC code. This animation might include coloured blocks and symbols that might move over the display of the Validator. The database is identical on all Validators used for Tokens that claim to be part of a Set-of-Valid-Tokens.

Because the new loC code may be the same on every Validator of a Set-of-Valid-Tokens, the same Animated loC Transition will synchronously appear on all Validators of a Set-of-Valid-Tokens. As the animation covers the whole display of the Validator, the social control scheme is even more visible from a remote distance. Therefore, use of an invalid Token may become even more difficult as a fraudulent party would have to mimic an unpredictable animation on his own fake Validator synchronously with all Validators of the Set-of-Valid-Tokens.

In order to increase further the security measures, the processor unit of the Validator 20 may further generate the PoT code 16. The PoT code 16 is generated by a Message Authentication Code (MAC) function 24 programmed on the Validator processor unit using as input the MAC Data 49 comprising, preferably consisting of, the Displayed Trust Data 45 and the displayed loC code 15 all shown on the Validator display 17. The PoT code 16 may be uniquely different for each Token 11 and may be used to verify whether all information shown on the Validator display 17 may be authentic. This is because, the PoT code 16 is based on the displayed loC code 15 and the displayed Trust Data 45, that may be different for each Token Owner. The MAC function 24 programmed in the processor unit 21 may be implemented by any of the MAC algorithms defined in up to date authentication and/or cryptography practices, such as currently 3D-MAC, AES-MAC and H-MAC

Therefore, by using the Identification Device 10 of the present invention, even if a fraud perpetrator is able to copy a correct loC 15 from a Validator 20 from the Set-of-Valid-Tokens and even if he succeeds in displaying this loC 15 instantly on the display of his fake Validator 20, he may not be able to display the correct PoT code 16 if he does not have the correct MAC Function 24. Because this function may only be known to the Trust Authority, the fraud perpetrator will not be able to get hold of the correct MAC function 24, thereby he will not be able to generate the correct PoT 16, except by chance. In addition, the loC code 15 may change at each time point of the Set-of-Time-Points 52. This preventative measure may have as an effect that the loC code 15 and the PoT code 16 may be re-generated by the Validator processor unit 21 at each time point of the Set-of-Time-Points 52. The regeneration of the loC code 15 may also result in the regeneration of the PoT code 16, making the use of invalid Tokens in a security environment even more infeasible.

For example, in the case where an invalid Token is presented to the Validator 20, it will become immediately apparent that it is not valid since the loC-code 15 and PoT-code 16 displayed in the Validator display 17 will not be correct or not generated at all, thereby indicating an invalid Token.

The Trust Authority may be arranged to identify invalid Tokens and/or invalid Validators. This may be possible by re-generating the loC 15 and PoT code 16 for each Validator based on the Indicator-of-Clearance-Function 23, the MAC function 24, the required Clearance Status 46 and the Time Rules 34 which are all known by the Trust Authority. The Trust Authority can thus independently control if the loC-code 15 and PoT-code 16 displayed on any Validator 20 are correct based on th¾ displayed Trust Data 45. Because the loC 15 and PoT 16 codes are visible on the display 17, they may be visually checked such that, when the display is visibly positioned by the Owner, the Validator 20 and Token 11 can be "checked without having to approach the Owner. Moreover, by displaying the Trust Data 45, the loC code 15 and the PoT code 16, a large number of Tokens 11 may be checked from a distance.

In the case where an invalid Validator device is used for authentication, such a device may not be able to connect to the Centralised System 30, thereby an invalid Validator device would not be able to obtain the required information such as the Time Rules 34, Clearance Rules 32, etc. As a result the codes displayed may either be wrong, e.g. random data, or may not change at predetermined intervals defined by the Time Rules.

To further increase the security measures, Indicator Rules 33 may be further imposed by the Centralised system 30 and transferred to the Validator 20 at the Initialization Phase to be used by the Indicator-of-Clearance Function 23 for the generation of loC codes 15. The Indicator Rules 33 can be a set of confidential rules determined by the Centralised System 30, which may for example only be valid for a predefined time period of the Set-of-T^'ime- Points, e.g. a predefined period until the end of a working day. Using the Indicator Rules 33, the Trust Authority may allow for the Indicator-of-Clearance Function 23 to become public while maintaining the Indicator Rules secret. As a result, if an instance of the Indicator Rules become known to the public, it would be sufficient for the Trust Authority to generate a new set of secret Indicator Rules 33 for a new time period^* to ensure that the Proof-of-Trust System is again reliable, thereby adding a further security feature in the Validator 20 for detecting the use of invalid Tokens. The Indicator Rules 33 are identical on all Validators 20 for Tokens 11 that are or want to become members of a Set-of-Valid-Tokens, thereby ensuring that the loC is calculated in the same manner on all these Validators.

The combination of Indicator Rules 33 with an Indicator-of- Clearance Function may be exemplified by a Validator device, which uses a hash function as an Indicator-of-Clearance Function 23 with a 3 digit output. For example, the Indicator Rules 33 may be equal to a single random 100 digit number generated by the Centralize System 30, which may be equal on all Validators 20 used for a specific Set-of-Valid-Token. As a result, the loC 15 would be generated by the hash function based on the calculated Clearance Status 46, the 100 digit random number and a specific time point from the Set- of-Time-Points 52.

Furthermore, in order to further increase the level of security, Trust Rules 35 may be further imposed by the Centralised system 30 and transferred to the Validator 20 at the Initialization Phase to be used by the MAC function 24 for the generation of PoT codes 16. Similarly as the Indicator Rules 33, Trust Rules 35 can be used as input of the MAC Function 24 programmed in the Validator process^*or21 to generate the PoT-code 16. The Trust Rules 35 can be a set of confidential rules determined by the Centralised System 30, which may for example only be valid for a predefined time period of the Set-of -Time-Points, e.g. a predefined period until the end of a working day. Using the Trust Rules 35, the Trust Authority may allow for the MAC Function 24 to become public while maintaining the Trust Rules secret. As a result, if an instance of the Trust Rules become known to the public, it would be sufficient for the Trust Authority to generate a new set of secret Trust Rules 35 for a new time period to ensure that the Proof-of-Trust System is again reliable, thereby adding a further security feature in the Validator 20 for detecting the use of invalid Tokens. The Proof-of-Trust Function may include cryptographic MAC functions with a secret key in which case the Trust Rules 35 may include a secret key for those cryptographic MAC functions 24. The Trust Rules 35 are identical on all Validators 20 for Tokens 11 that are or want to become members of a Set-of-Valid-Tokens, thereby ensuring that the PoT is calculated in the same manner on all these Validators.

According to embodiments of the present invention, all communication interfaces between the components of the Proof-of-Trust system may be physically wired when information has to be exchanged between the components avoiding the use of a wireless network at any stage of this embodiment of the present invention. In this case the Validator communication interfaces 25 and 26 used to communicate with the Token 11 and the Connector device 27 may be a wired interface. For example, the Token 11 , Validator 20 and the Connector 27 may be provided with physical contacts for this purpose. Therefore, for transferring data between different devices, a physical contact may be created between the different devices. This physical contact may be of a short time period (e.g. less then 1 second) and may serve to transfer the data required to execute and close the Initialisation Phase. Once Validators or Controllers enter their Operational Phase, the wired interface may be interrupted. Furthermore, the Connectors 27 may further be physically connected with the Centralised System 30 through a wired network.

Alternatively, communication interfaces between the components of the Proof-of-Trust system can also be over a secure wireless network during the Initialisation Phase when information may be exchanged between the different components of the system. For example, such a communication interface may be realised by means of Near Field Communication (NFC), Bluetooth, etc. In this way communication can be established remotely. Once Validators or Controllers enter their Operational Phase, the wireless network connection may be interrupted.

The Centralized System 30 may be provided with a Connector device(s) 27 and may contain a Centralised System clock 31 to which all devices in the Proof-of-Trust System may be synchronised. The Connector may be adapted to interact with the Validator communication interface 26 to transfer data between the Validator 20 and the Centralized System 30. The Centralised System 30 may be used by a Trust Authority to provide information to the Validator 20 through the Connector 27 transferred through a secure communication channel established by the Connector 27. Furthermore, the Connector device 27 may be adapted to transfer data such as Time Rules 34 and Clearance Rules 32 specifying whether the Clearance Data 44 stored in the Token 1 indicates that the object or person is allowed to perform an action. The Connector device 27 may further be adapted to transfer the Indicator Rules 33 and/or Trust Rules 35.

The Centralised System 30 may be stored in a server located in the vicinity of the Trust Authority, or may be stored in a server placed at a secure outsourced location under the supervision of the Trust Authority. Therefore, access to the information storied therein may only be limited to the Trust Authority.

In order to provide an easy authentication procedure having a high throughput, an electronic device may be provided by the Trust Authority to quickly control and authenticate the Validators and associated Tokens of a Set- of-Valid-Tokens, referred to hereinafter as a Controller 60. An example of a Controller 60 is shown in Figures 5.J5 and 7. The Controller allows the Trust Authority to delegate its controlling capability to any other party.

The Controller device 60 may be configured for checking the Trust Data 45, loC code 15 and PoT code 16 visible on a large number of Validators 20 of Tokens 11 that are or are not member of a specific Set-of- Valid-Token. The Controller 60 may be provided with a display 68 for displaying information, with a processor unit 62 used for processing information, with stored software programs and with storage space for input and output data. A capturing device 69 may further be provided that can collect the information on the display of a Validator 20 and enter this information into the processor unit of the Controller 62, such as an OCR (Optical Character Recognition) camera or a keyboard. The Controller may further include an internal clock 61 , a communication interface 70 to transfer data between the Controller 60 and the Centralized System 30 through a Connector 27. The communication interface 70 can be wired or wireless. The Controller 60 may have a Secure Element 63 that enables the Trust Authority to verify the authenticity of a Controller 60 at any point in time. The Controller may be adapted to generate a required loC code 73 and a required PoT code 74 using an Indicator-of-Clearance Function 64 and a MAC function 65. The Controller 60 may also contain a Time Function 67 to calculate a Set-of-Time-Points. The Indicator-of-Clearance Function 64, the .MAC function 65 and the Time Function 66 of the Controller are identical to the corresponding Indicator-of- Clearance Function 23 the MAC function 24 and the Time Function 51 on the Validators 20 of the Tokens that claim to be member of the Set-of-Valid- Tokens. The Indicator-of-Clearance Function 64, the MAC function 65 and the Time Function 66 may be stored in a secure and encrypted database 56 of the Controller and used as programs on the processor unit 62.

Prior to using the Controller 60 for authenticating and validating the information displayed on the Validator display 17, an Initialisation Phase represented by the solid arrows maybelnitiated as shown in Figures 6 and 7. During this Initialisation Phase, the Controller 60 may transfer the required information from the Centralised System 30 for authenticating and validating the information displayed on a Validator display 17. The Controller may first be connected to the Centralised System 30 belonging to the Trust Authority through a Connector 27 preferably in a fully secure and confidential manner. Through the Connector 27 a set of data may be transferred, which may comprise a clock synchronization signal for synchronizing the Controller clock 61 to the clock of the Centralized System 31. The Centralized System 30 may further transfer the required Clearance Status 71 and, if applicable, the Time Rules 34, the Indicator Rules 33 and/or the Trust Rules 35. This information is identical to the ones transferred to the Validators of the Tokens that claim to be member of a Set-of-Valid-Tokens. Therefore, based on the Time Rules 34 and the Time Function 66, the Controller 60 may generate the same Set-of-Time- Points 52 as the Validators that are used for the Set-of-Valid-Tokens.

After this Initialisation Phase, the Controller enters the Operational Phase which is represented by the dotted arrows in Figures 6 and 7. Using the required Clearance Status 1 and, if applicable, the Indicator Rules 33 and the Set-of-Time-Points 52 as input, the Indicator-of-Clearance Function 64 programmed on the processor unit 62 of the Controller 60 may regenerate the required loC code 73 which should be the same as the ioC code 15 visible on all Validators of Tokens that are member of a Set-of-Valid-Tokens at a given time point, The Controller 60 may now proceed with the validation of the information displayed on a Validator display 17. The validation procedure may be performed by first capturing the data visible on the display 17 of the Validator 20, namely the visible Trust Data 45, the visible IoC code 15 and the visible PoT code 16. This captured d¾ta^* may then be used as an input to the processor unit 62 of the Controller 60.

The processor unit 62 of the Controller 60 compares the displayed IoC 15 with the required |oC 73 at the time point that the Controller 60 executes the control. If they match, the Identification Device 10, including the Validator 20 and the Token 11 , may be considered as valid and the Controller 60 may display the comparison results on the Controller display 68.

The processor unit 62 of the Controller 60 may further calculate the required PoT 74 by using as input the displayed Trust Data 45, the displayed IoC code 15 and, if applicable, the Trust Rules 35 in the MAC function 65. The required PoT 74 generated by the processor unit 62 of the Controller may then be compared with the displayed PoT 16 of the Validator 20. In the case where the PoT codes 16 and 74 match, the Identification Device 10, including the Validator 20 and the Token 11 , may be considered as authentic. The Controller 60 may further display the results of such PoT comparison on the Controller display 68.

Through these steps, the Controller may execute an extended verification of an Identification Device 10: if both loC codes 15 and 73 and PoT codes 16 and 74 match, the Identification Device 10 may be valid and authentic; if the PoT codes 16 and 74 match but the loC codes 15 and 73 do not match, the Identification Device is authentic but not valid; if the PoT codes 16 and 74 do not match, the Identification Device 10 is not authentic, in other words fake, and also not valid, independent of the results of the loC codes 15 and 73 comparison.

In the case where one or both security codes displayed in the Validator 20 are not correct, a further check may be performed by a close up inspection using a Controller 60 adapted to communicate with the Token 11 , such a device may include a mobile phone that is NFC compatible and that has an applet with the functionalities of a Controller.

An integrated Proof-of-Trust System for authenticating the information stored in a Token may be formed comprising a Centralised System 30 of a Trust Authority, Identification Devices 10 comprising Tokens 11 and Validators 20, Connectors 27 and Controllers 60 according to embodiments of the present disclosure.

By using such a Proof-of-Trust System, most type of fraud, invalid use or falsified use of a Token may be identified in a quick, consistent and continuously visible manner. The use of the Proof-of-Trust System may be exemplified in the following situations:

In the case where a valid Validator is used in combination with an authentic Token that does not have the required Clearance Data, the Validator will identify the Token as invalid apd show no valid data, for example an invalid loC but a valid PoT on its display, thereby enabling social control from all Owners of valid Tokens. In this case the Controller can identify the Validator as invalid but as authentic, and thus not as fake.

In a further example, where a valid Validator is used in combination with a Token having fake visible data on the Token and an fake chip, the Validator will identify the Token as fake. Therefore, in the Validator display no valid loC code and no PoT code will be shown, thereby enabling social control from all Owners of valid Identification Devices. In this case the Controller will identify the Identification Device as containing a non authentic, fake component. " '

In yet another example, the use of a fake Validator showing fraudulent Identification Data and a random loC and random PoT, will be identified by the Controller as invalid and not authentic because the loC code and the PoT code of this Validator will be different from the one calculated by the Controller except by chance. This also enables social control from all Owners of valid Tokens with authentic Validators.

In another example, the use of a fake Validator showing fraudulent Identification Data, an loC code which is instantly copied from a valid Validator from the Set-of-Valid-Tokens and a random PoT, will be identified by the Controller as not authentic and thus fake.

In yet another example, a real Validator device may be combined with a real Token stolen from its Owner. The Token is stolen before the Validator and Token passed the Initialisation Phase and the Token Owner has announced the Token as stolen,tq,the Trust Authority. In this case, the Token will be recognized as stolen at the next Initialisation Phase and blocked for further use. The Validator will then identify the Token as blocked and show for example no valid data, no loC but a correct PoT on its display, enabling social control from all Owners of valid Tokens. Therefore, the Controller will identify the Validator as invalid but authentic.

In a further example, a real Validator device may be combined with a real Token stolen from its Owner. The Token may be stolen after the Token passed the Initialisation Phase or the Owner did not announce the Token as stolen to the Trust Authority. Furthermore, the ID-photo of the Owner may be stored in the Token and is shown in the display of the Validator. As a result, the ID-photo shown on the display of the Validator will be different from the person carrying the Validator and Token, enabling social control to identify the person carrying the Validator as different from the Owner.

In another example, a real Validator device may be combined with a real Token stolen from its Owner. The Token was stolen after the Token passed the Initialisation Phase or the Owner did not announce the Token as stolen to the Trust Authority. The ID-photo of the Owner is not shown in the display of the Validator. A fake ID^phpto may therefore be printed on the Token. In this case, in order to avoid this type of fraud, it is recommended that the Trust Authority shows the ID-photo contained in the memory of the Token on the display of the Validator. The Token will also be blocked once the Trust Authority knows that the Token is stolen. Moreover, the photo can be part of the Trust Data such that when a fake ID-photo is printed onto the Token, the PoT code will no longer be correct, making the fake Identification Device 10 detectable.

In yet another example, a fraud perpetrator is able to create a fake Owner of a Token in the Centralised System, to obtain a real Validator and to generate an associated technical real Token with fake Clearance Data. In this case, the fraud is not detectable. However, this type of fraud is not feasible if the Trust Authority is organised and implemented according to standard good practice in cryptography.

Claims

Claims

1. An Identification Device (10) for providing validation information comprising:

- a Token (11) comprising a memory for storing information of a person or object, such information comprising Identification Data (43) comprising a first subset representing security Clearance Data (44), said Identification Data being arranged to uniquely identify the person or object; and,

- a Validator (20) comprising a display (17), a processor unit (21 ), a Validator clock (28) and Validator communication means (25,26) for interacting with the Token (1 ) and with a Connector (27) of a Centralized System (30) adapted to securely transfer data during an Initialisation Phase between the Centralized System (30) and the Validator (20) through the Connector (27), such data comprising a clock synchronization signal for synchronizing the Validator clock (28) to a Centralized system clock (31 ) of the Centralized System (30), and Clearance Rules (32) specifying whether the Token (11 ), based on the Clearance Data (44) stored in the Token (11 ), can be given a specific Clearance Status (46) that indicates that the object or person is allowed to perform an action or obtain a valid status;

wherein the display (17) is further adapted to display, during an Operational Phase, a first security code (15), referred to as the Indicator-of-Clearance code or loC code (15), indicating the Clearance Status (46) of the Token, whereby the first"security code (15) is generated by an Indicator-of-Clearance Function (23), such as a digital signature or hash function, programmed on the processor unit (21 ) based on the Clearance Status (46) and the Validator Clock (28).

2. An Identification Device (10) according to claim 1 for providing validation information, wherein the Identification Data (43) comprises a second subset representing Trust Data (45), wherein the display (17) is adapted to display the Trust Data (45) stored in the Token (11) and wherein the display (17) is further adapted to display, during the Operational Phase, a second security code (16), referred to as the Proof-of-Trust code or PoT code (16), generated by a Message Authentication Code function or MAC function (24) programmed on the processor unit (24 ) based on the Trust Data (35) on the Validator display (17) and the first security code (15).

3. A Centralized System (30) comprising a Connector (27) and a clock (31 ), wherein the Connector (27) is adapted to securely interact with the Validator communication means (26) to transfer data during the Initialisation Phase between the Centralized System (30) and the Validator (20), such data comprising a clock synchronization signal for synchronizing the Validator clock (28) to the Centralized System clock (31 ), and Clearance Rules (32) specifying whether the Clearance' Data (46) stored in the Token (1 1 ) indicates that the object or person is allowed to perform a valid action or obtain a valid status.

A Proof-of-Trust-System comprising:

At least one Identification Device (10) according to claim a Centralized System (30) according to claim 3.

5. An Identification Device (10) or a Centralized System (30) or a Proof-of-Trust-System according to any one of the preceding claims, wherein data being transferred during the Initialisation Phase between the centralized system and the Validator comprises a set of Time Rules (34), said Time Rules (34) enabling the processor unit (21 ) to calculate by a Time Function (51 ) programmed on the processor (21 ), a set of time intervals, referred to as Set-of-Time-Points (52), said Set-of-Time-Points (52) being provided as input to the Indicator-of-Clearance Function (23) such that respective Indicator-of-Clearance codes (15) are generated for each of the time intervals.

6. An Identification Device (10) or a Centralized System (30) or a Proof-of-Trust-System according to claim 5, wherein the Time Rules (34) further define a time limit period at which the Operational Phase ends and the Validator (20) stops generating Indicator-of-Clearance codes (15) and/or Proof-of-Trust codes (16) until a new Initialisation Phase occurs.

7. An Identification Device (10) or a Centralized System (30) or a Proof-of-Trust-System according to claim 5 or 6, wherein the respective Indicator-of-Clearance coctesr(15) are generated by the Indicator-of- Clearance function (23) and are identical on all the displays (17) of all the Validators (20) with Tokens (11 ) that are authentic and have the same valid Clearance Status.

8. An Identification Device (10) or a Centralized System (30) or a Proof-of-Trust-System according to any one of the preceding claims, wherein the processor unit (21 ) of each Validator (20) is adapted so that each potential Indicator-of-Clearance code has a corresponding uniquely different Animated Indicator-of-Clearance Transition codified in a database of Animated Indicator-of-Clearance Transitions in the Validator (20) and to be displayed on the display of the Validator (20) prior to showing the new corresponding Indicator-of-Clearance code (15), and wherein the Animated Indicator-of- Clearance Transition database is identical for all Validators (20) so that the same Animated Indicator-of-Clearance _^Transition appears in a synchronous manner on all Validators (20) of Tokens (11) with the same valid Clearance Status (46).

9. An Identification Device (10) or a Centralized System (20) or a Proof-of-Trust-System according to any one of the preceding claims, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Validator (20) comprises a set of Indicator Rules (33) used as additional input by the Indicator-of-Clearance function (23) to generate the Indicator-of-Clearance code (15).

10. An Identification Device (10) or a Centralized System (20) or a Proof-of-Trust-System according to any one of the preceding claims at least in combination with claim 2, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Validator (20) comprises a set of Trust Rules (35) used as additional input by the MAC function (24) to generate the Proof-of-Trust code (16).

11. An Identification Device (10) or a Centralized System (30) or a Proof-of-Trust-System according to any one of the preceding claims, wherein the Validator (20) further comprises a memory for storing the Clearance Rules (32) and if present Time Rules (34), Trust Rules (35) and Indicator Rules (33). 12. An Identification Device (10) or a Centralized System

(30) or a Proof-of-Trust-System according to any one of the preceding claims, wherein the Validator communication means (25, 26) used during the Initialisation Phase comprises exclusively wired communication means, such as cables, contacts, etc.

13. An Identification Device or a Centralized System (30) or a Proof-of-Trust-System according to any one of the preceding claims, wherein the Token and the Validator {20~) are integrated into a single device. 14. A Proof-of-Trust-System according to any one of the preceding claims at least in combination with claim 4, further comprising a Controller (60) for validating the information displayed on the Identification Device (10) of claim 1 and for verifying \\ the Token (11 ) of a particular Identification Device (10) is a member of a Set-of-Valid-Tokens, wherein the Controller (60) comprises means (69) for capturing the data displayed on the Identification Device (10) including the displayed Indicator-of-Clearance code (15), a display (68), a processor unit (62), a Controller clock (61 ) and Controller communication means (70) for securely interacting during an Initialisation Phase with a Connector (27) of the Centralized System (30) , whereby the Connector (27) is adapted to transfer data from the Centralized System (30) through the Connector (27) during the Initialisation Phase, such data comprising a clock synchronization signal for synchronizing the Controller clock (61 ) to a Centralized System clock (31 ) of the centralized system (30) and the Clearance Status (71 ) for all the Tokens (11) of the Set-of-Valid-Tokens, wherein the processor unit (62) of the Controller (60) is further adapted to generate the Indicator-of-Clearance code^* (73) by the Indicator-of-Clearance Function (64) programmed on the Controller processor unit (62) based on the Clearance Status (71) and the Controller Clock (61 ).

15. A Proof-of-Trust-System according to claim 14 at least in combination with claim 2, wherein the means (69) for capturing the data displayed on the Identification Device (10) includes the displayed Trust Data (45) and the displayed Proof-of-Trust code (16), wherein the Proof-of-Trust code (74) is generated by the MAC function (65) programmed on the processor unit (62) of the Controller (60) based on the displayed loC code (15) and the displayed Trust Data (45) shown on the Validator display (17) of the Identification Device (10). 16. A Proof-of-Trust-System according to claim 14 or 15, preferably claim 15, wherein the processor unit (62) of the Controller (60) is adapted to display the result of a comparison between the Indicator-of- Clearance code (73) , and preferably the Proof-of-Trust code (74), generated in the processor unit (62) of the Controller (60) and the loC code (15), and preferably the PoT code (16), displayed on an Identification Device (10) captured by the means for capturing visible information.

17. A Proof-of-Trust-System according to any one of claims 14 - 16, wherein the means for capturing information (29) of the Controller (60) may comprise a device adapted to' optically capture and convert the information displayed in the Identification Device of claim 1 to a digital format using an Optical Character Recognition interface, such as a camera.

18. A Proof-of-Trust-System according to any one of claims 14 - 17 at least in combination with claim 5, wherein data being transferred during the Initialisation Phase between the centralized system and the Controller (60) comprises the set of Time Rules (34), said Time Rules (34) enabling the processor unit (62) to calculate by the Time Function (51 ) programmed on the processor (62), the set of time intervals, referred to as the Set-of-Time-Points (52), said Set-of-Time-Points (52) being provided as input to the Indicator-of-Clearance Function (64) such that respective Indicator-of- Clearance codes (73) are generated for each of the time intervals. 19. A Proof-of-Trust-System according to any one of claims

14 - 18 at least in combination with claim 9, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Controller (60) comprises the set of Indicator Rules (33) used as additional input by the Indicator-of-Clearance function (64) to generate the Indicator-of-Clearance code (73).

20. A Proof-of-Trust-System according to any one of claims 14 - 19 at least in combination with claim 10, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Controller (60) comprises the set of Trust Rules (35) used as additional input by the MAC function (65) to generate the Proof-of-Trust code (74).

21. A method for validating the information displayed on the Identification Device (10) according to any one of claims 1 - 20, comprising the steps of :

initialising the Validator (20) comprising the steps of : presenting a Token (1 ) containing information of a person or object to the Validator (20), such information comprising Identification Data comprising a first subset representing Clearance Data (44) and a second subset representing Trust Data (45), which Identification Data (43) uniquely identifies the person or object; connecting the Token (11) to the Validator (20) through the Validator communication means (25), thereby allowing the Validator (20) to access the information stored in the memory of the Token (11 ); connecting the Validator (20) to a Connector (27) of a Centralized System (30) through the Validator communication means (26); transferring data between the Validator (20) and the Centralized System (30) during an Initialisation Phase through the Connector (27), such data comprising a clock synchronization signal for synchronizing the Validator clock (28) to a Centralized system clock (31 ) of the Centralized System (30), and Clearance Rules (32) specifying whether the Token (11 ), based on the Clearance Data (44) stored in the Token (11 ) can be given a specific Clearance Status (46) that indicates that the object or person is allowed to perform a valid action or obtain a valid status; and

operating the Validator (20) during an Operational Phase for validating the information in a Token (11) comprising the step of: generating a first security code ( 5), referred to as the Indicator-of-Clearance code (15), indicating the Clearance Status (46) of the Token, whereby the first security code (15) is generated by an Indicator-of-Clearance Function (23), such as a digital signature or hash function, programmed on the processor unit (2 ) based on the Clearance Status (46) and the Validator Clock (28).

22. The method according to claim 21 , wherein the Validator (20) during the Operational Phase for validating the information in a Token (11 ) comprises the step of generating a second security code (16), referred to as the Proof-of-Trust code (16), generated by a MAC function (24) programmed on the processor unit (21 ) based on the Trust Data (35) on the Validator display (17) and the first security code (15); and further displaying on the display (17) of the Validator (20) the first security code (15) and the second security code (16).

23. The method according to any one claims 21 - 22, preferably claim 22, wherein validation of the information displayed on the Identification Device further comprises-the steps of:

providing a Controller Device (60) arranged to validate the information displayed on the display (17) of the Validator (20);

initialising the Controller (60) by performing sequentially the steps of: connecting the Controller (60) using the communication interface (70) to the Centralised System (30) of the Trust Authority through a Connector (27); transferring the data during an Initialisation Phase, such data comprising a clock synchronization signal for synchronizing the Controller clock (61 ) to the clock of the Centralized System (31) and the Clearance Status (71 ) for all the Tokens (11) of the Set-of- Valid-Tokens; generating during the Operational Phase in the processor unit (62) of the Controller (60) through the Indicator-of-Clearance Function (64) the loC code (73) using as input the Clearance Status (71);

capturing during the Operational Phase the data visible on the display (17) of the Validator (20) and providing such captured data as an input to the processor unit (62) of the Controller (60);

comparing the displayed loC (15) visible on the Validator (20) to the loC (73) generated by the processor unit (62) of the Controller (60);

displaying the comparison results on the Display of the Controller (68).

24. The method according to claim 22 and 23, wherein the PoT code (74) is generated through the MAC function (65) programmed on the processor unit (62) of the Controller (60) using as input the previously generated loC code (15) and the displayed Trust Data (45) visible on the Validator display (17), wherein the PoT code (74) generated by the processor unit (62) of the Controller (60) is compared to the displayed PoT code (16) visible on the Validator (20) and wherein the results of the comparison on the display of the Controller (68) is displayed.

25. The method according to any one claims 21 - 24, wherein the processor unit (21) of each Validator (20) is adapted so that each potential Indicator-of-Clearance code has a corresponding uniquely different Animated Indicator-of-Clearance Transition codified in a database of Animated Indicator-of-Clearance Transitions in the Validator (20) and wherein the Animated Indicator-of-Clearance Transitions are displayed on the display of the Validator (20) prior to showing the new corresponding Indicator-of-Clearance code (15), and wherein the Animated Indicator-of-Clearance Transition database is identical for all Validators (20) so that the same Animated Indicator-of-Clearance Transition appears in a synchronous manner on all Validators (20) of Tokens (11 ) with the same valid Clearance Status (46).

26. The method according to any one claims 21 - 25, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Validator (20) comprises a set of Indicator Rules (33) used as additional input by the Indicator-of-Clearance function (23) to generate the Indicator-of-Clearance code (15).

27. The method according to claim 26 at least in combination at least in combination with claim 23 or 24, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Controller (60) comprises the set of Indicator Rules (33) used as additional input by the Indicator-of-Clearance function (64) to generate the Indicator-of-Clearance code (73).

28. The method according to any one claims 21 - 27, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Validator (20) comprises a set of Trust Rules (35) used as additional input by the MAC function (24) to generate the Proof- of -Trust code (16).

29. The method according to claim 28 at least in combination with claim 23 or 24, wherein the data being transferred during the Initialisation Phase between the Centralized System (30) and the Controller (60) comprises the set of Trust Rules (35) used as additional input by the MAC function (65) to generate the Proof-of-T rust code (74).

30. The method according to any one of claims 21 - 29, wherein the data being transferred during the Initialisation Phase between the centralized system and the Validator comprises a set of Time Rules (34), the processor unit (21 ), enabled by the Time Rules (34), calculating by a Time Function (51) programmed on the processor (21), a set of time intervals, referred to as Set-of-Time-Points (52), said Set-of-Time-Points (52) being provided as input to the Indicator-of-Clearance Function (23) such that respective Indicator-of-Clearance codes^* (15) are generated for each of the time intervals.

31. The method according to claim 30 in combination with at least claim 23 or 24, wherein the data being transferred during the Initialisation Phase between the centralized system and the Controller (60) comprises the set of Time Rules (34), the processor unit (62), enabled by the Time Rules (34), calculating by the Time Function (51 ) programmed on the processor (62), the set of time intervals, referred to as the Set-of-Time-Points (52), said Set-of- Time-Points (52) being provided as irjput to the Indicator-of-Clearance Function (64) such that respective Indicator-of-Clearance codes (73) are generated for each of the time intervals.