WO2017191472A1

WO2017191472A1 - A verification system and method

Info

Publication number: WO2017191472A1
Application number: PCT/GB2017/051264
Authority: WO
Inventors: Christopher LANIGAN; Steven WHITCHURCH; Scott Alexander
Original assignee: Invasec Ltd
Current assignee: Invasec Ltd
Priority date: 2016-05-05
Filing date: 2017-05-05
Publication date: 2017-11-09
Anticipated expiration: 2018-11-05

Abstract

A verification method comprises providing verification data for verifying the authenticity of a data package, the verification data being identified by an identifier. The method comprises storing the verification data in a storage system (1), the storage system (1) being configured to prevent an unauthorised party from modifying the verification data. The method further comprises receiving a request for the verification data from a client device (2), the request comprising at least the identifier, providing the verification data to the client device (2) in response to the request, and verifying the authenticity of a data package (8) at the client device (2) using the verification data. There is also provided a system for performing the verification method.

Description

A verification system and method

Technical field The present invention relates to a verification system and method, and more particularly relates to a computer implemented verification system and method.

Background A public key infrastructure (PKI) is an arrangement for creating, managing, distributing, using, storing and revoking digital certificates and for managing public key encryption. A PKI facilitates secure electronic transfer of data files by enabling a user to verify the authenticity of data files. A conventional distributed signing solution requires a PKI to be in place to enable public keys that are sent or received by a client to be verified. A store of trusted root certificate authority (CA) certificates is stored on a client device. Any public certificate that is received by the client device is verified against the trusted root CA certificates and, if verification is successful, the public certificate is considered valid and safe for use by the client device.

A problem arises in a conventional PKI if a root CA certificate is missing from a client device because the client device cannot verify the authenticity of all public certificates.

A further problem can arise if a malicious party manages to store their own root CA certificate on a client device. If a malicious party is successful in doing this then certificates or signatures issued by the malicious party will be considered valid by the client device, thereby enabling the malicious party to execute unsafe or untrustworthy code on the client device.

In a conventional PKI, a client device must also check if a public certificate has been revoked. The client device does this by checking the serial number of the certificate against a certificate revocation list or online certificate status protocol provided by a certificate revocation infrastructure. If this check reveals that the certificate has been revoked then the client device does not use the certificate.

A conventional PKI relies on access to a certificate revocation infrastructure. If the revocation infrastructure is down or is unreachable, revoked certificates can remain in service, making users vulnerable to exploitation by malicious parties.

In a conventional PKI, there is also a risk that a certificate authority can be compromised by a malicious party and induced to issue certificates on behalf of the malicious party. At present, over 200 signing authority certificates need to be installed on OSX and Windows based computers. If any one of the certificate authorities is compromised by a malicious party then it would be possible for the malicious party to issue fake/fraudulent certificates that appear to be legitimate certificates issued by the certificate authority. The malicious party can then use the fake certificates to enable malicious code to be executed on a client device. One example of this occurred in 201 1 when hackers breached the DigiNotar certificate authority and issued fraudulent certificates.

Another example of a security breach to a conventional PKI occurred in connection with the malicious Stuxnet worm. In this breach, two genuine certificates were compromised when the private keys of the certificates were stolen from two companies in Taiwan. The compromised certificates remained undetected for a relatively long period of time, enabling the Stuxnet worm to install itself on computers without users being notified. The Stuxnet worm was therefore able to propagate widely throughout the Internet.

There is a need for an improved verification system and method that addresses at least the problems outlined above. The present invention seeks to provide an improved verification system and method. Summary of invention

According to one aspect of the present invention, there is provided a computer implemented verification method, the method comprising: providing verification data for verifying the authenticity of a data package, the verification data being identified by an identifier; storing the verification data in a storage system, the storage system being configured to prevent an unauthorised party from modifying the verification data; receiving a request for the verification data from a client device, the request comprising at least the identifier; providing the verification data to the client device in response to the request; and verifying the authenticity of a data package at the client device using the verification data.

Preferably, the identifier comprises a hash value of the data package. Conveniently, the method comprises using a hashing algorithm to calculate the hash value of the data package.

Advantageously, the hashing algorithm is a MD5 hashing algorithm. Preferably, the data package is a software data file.

Conveniently, the data package is a substantially unique identifier which identifies a physical item. Advantageously, the substantially unique identifier is a hash value computed from data linked to a physical item. Preferably, the method further comprises: revoking the verification data by preventing access to the verification data in the storage system or by removing the verification data from the storage system. In some embodiments, the verification data is a public key for use in a public key infrastructure (PKI).

Advantageously, the storage system is secured using a security function to prevent an unauthorised party from modifying the verification data.

In some embodiments, the storage system is a blockchain.

In some embodiments, the storage system is a memory in a domain name system (DNS) and the method comprises storing the verification data in a DNS record of the DNS.

Preferably, the method further comprises: preventing an unauthorised party from modifying the DNS record. Conveniently, the method further comprises: comparing a further public key with at least one public key stored in the DNS record, wherein if the further public key matches a public key stored in the DNS record the further public key is authentic, and if the further public key does not match a public key stored in the DNS record the further public key is not authentic.

Advantageously, the DNS is secured using domain name system security extensions (DNSSEC).

Preferably, the method further comprises: encrypting data sent between the client device and the DNS. Conveniently, the DNS is configured for encrypted communication with the client device using a DNSCrypt protocol.

Advantageously, the method further comprises: storing, in the DNS, an indication of a signing algorithm to be used with verification data stored in the DNS record.

Preferably, the method further comprises: storing, in a DNS record, a time to live (TTL) value for the verification data stored in the DNS record; and providing the TTL value to the client device with the verification data, the TTL value indicating a time period after which the verification data is discarded by the client device.

Conveniently, the method further comprises: providing a management server which is configured to communicate with the DNS; receiving a data file at the management server; verifying the authenticity of the data file at the management server by: requesting verification data from the DNS which corresponds to the data file; and using the verification data to verify the authenticity of the data file; wherein if the data file is verified as being authentic the method comprises storing the data file as a whitelisted data file in a memory of the management server and if the data file is not verified as being authentic the method comprises discarding the data file.

Advantageously, the method further comprises: computing a hash value from a data file stored in the memory of the management server; and storing the hash value with the data file in the memory of the management server.

Preferably, the method further comprises: computing a hash value from a further data file and comparing the computed hash value with a hash value stored in the memory of the management server to verify the authenticity of the further data file. Conveniently, the method further comprises: checking the number of DNS records stored in the DNS memory; and outputting an alert if there are a greater or fewer number of DNS records stored in the memory than a predetermined expected number of DNS records.

Advantageously, the method further comprises: encrypting data communicated between the client device and the storage system using the verification data.

Preferably, the method further comprises: sending a receipt data file from the client device to the storage system, the receipt data file being signed by the client device using key for non-repudiation.

Conveniently, the method further comprises: generating a one-time signing key pair comprising a public key and a private key; providing the public key to the client device; and removing the public key from the storage system to prevent the storage system from re-issuing or providing access to the same public key.

According to another aspect of the present invention, there is provided a computer readable medium storing instructions which, when executed by a processor, perform the steps of the method of any one of claims 1 to 26 as defined hereinafter.

According to a further aspect of the present invention, there is provided a verification system comprising: a storage system storing verification data, the verification data for verifying the authenticity of a data package and the verification data being identified by an identifier, wherein the storage system is configured to prevent an unauthorised party from modifying the verification data, and wherein the storage system is configured to provide the verification data to a client device in response to a request from the client device that comprises at least the identifier such that the client device can use the verification data to verify the authenticity of a data package. Preferably, the identifier comprises a hash value of the data package.

Conveniently, the system comprises a hashing module which is configured to use a hashing algorithm to calculate the hash value of the data package.

Advantageously, the hashing algorithm is a MD5 hashing algorithm.

In some embodiments, the data package is a software data file.

In some embodiments, the data package is a substantially unique identifier which identifies a physical item.

In some embodiments, the substantially unique identifier is a hash value computed from data linked to a physical item.

Preferably, the system is configured to revoke the verification data by preventing access to the verification data in the storage system or by removing the verification data from the storage system.

Conveniently, the verification data is a public key for use in a public key infrastructure (PKI).

Advantageously, the storage system is configured to provide a security function to prevent an unauthorised party from modifying the verification data.

In some embodiments, the storage system is a blockchain.

In some embodiments, the storage system is a memory in a domain name system (DNS) and the system is configured to store the verification data in a DNS record of the DNS. Preferably, the system is configured to prevent an unauthorised party from modifying the DNS record.

Conveniently, the system is configured to compare a further public key with at least one public key stored in the DNS record, wherein if the further public key matches a public key stored in the DNS record the system is configured to indicate that the further public key is authentic, and if the further public key does not match a public key stored in the DNS record the system is configured to indicate that the further public key is not authentic.

Preferably, the DNS is secured using domain name system security extensions (DNSSEC).

Conveniently, the system is configured to encrypt data sent between the client device and the DNS.

Advantageously, the DNS is configured for encrypted communication with the client device using a DNSCrypt protocol. Preferably, the DNS is configured to store an indication of a signing algorithm to be used with verification data stored in the DNS record.

Conveniently, the DNS is configured to store a time to live (TTL) value for the verification data stored in the DNS record, and the DNS is configured to provide the TTL value to the client device with the verification data, the TTL value indicating a time period after which the verification data is discarded by the client device.

Advantageously, the system further comprises: a management server which is configured to communicate with the DNS, the management server being configured to receive a data file and to verify the authenticity of the data file by: requesting verification data from the DNS which corresponds to the data file; and using the verification data to verify the authenticity of the data file; wherein if the data file is verified as being authentic the management server is configured to store the data file as a whitelisted data file in a memory of the management server and if the data file is not verified as being authentic the management server is configured to discard the data file.

Preferably, the system is configured to compute a hash value from a data file stored in the memory of the management server and store the hash value in the memory of the management server.

Conveniently, the system is configured to compute a hash value from a further data file and compare the computed hash value with a hash value stored in the memory of the management server to verify the authenticity of the further data file.

Advantageously, the system is configured to check the number of DNS records stored in the DNS memory and to output an alert if there are a greater or fewer number of DNS records stored in the memory than a predetermined expected number of DNS records.

Preferably, the system is configured to encrypt data communicated between the client device and the storage system using the verification data.

Conveniently, the system is configured to send a receipt data file from the client device to the storage system, the receipt data file being signed by the client device using key for non-repudiation.

Advantageously, the system is configured to generate a one-time signing key pair comprising a public key and a private key, provide the public key to the client device and remove the public key from the storage system to prevent the storage system from re-issuing or providing access to the same public key. Brief description of drawings

So that the present invention may be more readily understood, embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram showing a verification system of some embodiments, Figure 2 is a schematic diagram showing part of a DNS,

Figure 3 is a flow diagram showing the operation of a method of some embodiments, Figure 4 is a diagram illustrating a DNS record,

Figure 5 is a schematic diagram showing the source to destination validation of some embodiments, Figure 6 is a schematic diagram showing a validated chain of trust of some embodiments,

Figure 7 is a schematic diagram showing a vendor whitelisting operation of some embodiments,

Figure 8 is a flow diagram of a one time signing process of some embodiments,

Figure 9 is a sequence diagram showing the creation of a data package in some embodiments, Figure 10 is a schematic diagram showing the structure of a data packet created by some embodiments,

Figure 1 1 is a schematic diagram showing an implementation of a system of some embodiments involving the Internet of Things,

Figure 12 is a flow diagram showing the encapsulation of signatures through various providers in the operation of some embodiments, Figure 13 is a schematic diagram showing a web-verify implementation of some embodiments,

Figure 14 is a schematic diagram showing a product verification implementation of some embodiments,

Figure 15 is a schematic diagram showing a data verification implementation of some embodiments,

Figure 16 is a flow diagram showing the operation of some embodiments,

Figure 17 is a schematic diagram showing the operation of some embodiments, and

Figure 18 is a schematic diagram showing the operation of some embodiments.

Detailed description

The method and system of some embodiments uses verification data stored securely in a storage system, the verification data being identified by an identifier. The verification data is stored securely by the storage system being configured to prevent an unauthorised party from modifying or deleting the verification data.

The verification method comprises receiving a request from a client device for the verification data, the request comprising at least the identifier, and providing the verification data to the client device. The method further comprises verifying the authenticity of a data package at the client device using the verification data.

In some embodiments, the verification data is a key for use in a public key infrastructure (PKI). In other embodiments, as described below, the verification data is other verification data, such as a hash value or signature.

In some embodiments, the storage system is part of a domain name system (DNS) and is preferably a DNS server of a DNS. In other embodiments, the storage system is a different storage system from a DNS server. For instance, in other embodiments, the storage system is any other type of data storage system with a security function. In some embodiments, the storage system is a blockchain.

The DNS is an existing infrastructure which is critical to the operation of the Internet. The DNS provides a domain name service that is a basic requirement for most Internet based services and is supported by virtually all Internet connected devices.

The DNS is configured to translate a domain name into an IP address. When a client device wishes to browse or access data from a domain (e.g. a web page with the domain and page address identified by a URL), the client device transmits the domain information to a DNS. The DNS returns a corresponding IP address to enable the client device to communicate with a server or other device that is identified by the IP address. The existing DNS infrastructure is a separate infrastructure to the conventional PKI that operates throughout the Internet. The system and method of some embodiments combines the functionality of DNS with the functionality of PKI to solve the problems associated with the conventional PKI that is in use throughout the Internet.

A verification method and system of some embodiments will now be described with reference to figures 1 -4 of the accompanying drawings. The system of some embodiments comprises a storage system in the form of a DNS which is preferably an existing DNS available via the Internet. However, in other embodiments, the DNS is a purpose or custom built DNS. The DNS comprises a DNS server 1 which is configured to function as a DNS to provide a domain name service. The DNS server 1 acts as a storage system which is coupled for communication with a client device 2 and a management server 3 via a computer network, such as the Internet.

Referring now to figure 2 of the accompanying drawings, the DNS server 1 comprises a DNS memory 4 which stores a secured DNS record 5 corresponding to a domain name. The DNS memory 4 stores a plurality of DNS records 5a... x with each DNS record corresponding to a respective domain name. Each of the DNS records stores data corresponding to its respective domain name, such as a corresponding IP address for the domain name, an expiration time (time to live), class and type-specific data. The configuration and function of the DNS server 1 is familiar and well understood by those skilled in the art.

The management server 3 is configured to communicate with the DNS server 1 and the client device 2. The management server 3 of this embodiment is configured to provide verification data in the form of a public key and to link the public key to a domain name. Referring now to figure 3 of the accompanying drawings, the system operates by storing the public key in the DNS memory 4 with link data linking the public key to the DNS record which corresponds to the domain name. In a preferred embodiment, as shown in figure 4, a public key 6 is stored as part of the DNS record 5a along with name data 7 which corresponds to the domain name. The storage of the public key 6 within the data structure of the DNS record 5 provides the link data which links the public key 6 to the DNS record 5a and the corresponding domain name. The public key data 6 is stored securely within the DNS record 5a since the DNS record may only be modified by an authorised party, such as the controller of the domain.

The system is configured to distribute the public key to a client device by transmitting the public key to the client device in response to the client device polling the DNS server 1 for the DNS record for the corresponding domain name.

In some embodiments, the DNS is configured so that only an authorised controller of the domain is permitted to control or modify the DNS record. Therefore, only the authorised controller can modify the public key stored in the DNS record. The system is therefore configured to prevent an unauthorised third party from modifying the DNS record or the public key. Since the public key is retrieved from the secured DNS record, there is no requirement for root certificate authority (CA) certificates to be stored on a client device. The client device can therefore obtain the public key data from the secured DNS record and be confident that the public key data is authentic. If a client device only uses embodiments of the invention to obtain a public key from a DNS record then there is no risk to the client device being compromised by a malicious party placing a compromised certificate or public key on the client device. The DNS record is secured and it is not possible for a malicious third party to place its own certificate or public key within the DNS record. In some embodiments, a public key can be revoked by the authorised domain controller simply modifying or removing the DNS record so that the DNS can no longer provide the public key. It is easy for the DNS controller to revoke their public key with a simple instruction to the DNS to modify or remove the DNS record containing the public key. As an authorised DNS controller, a user or organisation therefore has full control over their own public keys and public certificates via the DNS. In addition, a user or organisation can easily poll the DNS in order to verify their own public key or certificate at any time.

The DNS infrastructure is the only infrastructure required to implement PKI in some embodiments. Unlike the conventional PKI that is in use throughout the Internet, in some embodiments there is no requirement for a separate certificate revocation infrastructure for revoking certificates. The system and method of some embodiments is therefore only reliant on the operation of the DNS infrastructure. The system is not compromised or taken down when another infrastructure, such as the certificate revocation infrastructure is down or otherwise unavailable.

A further benefit of some embodiments is the reduced cost to end users or organisations compared with a conventional PKI. In a conventional PKI, a user or organisation is typically required to pay a certificate authority to sign a public key and this can be expensive. By contrast, embodiments of the invention permit a user or organisation to create their own public key and upload and store the public key within the DNS. The user or organisation is no longer required to pay a certificate authority. Apart from the cost of the DNS service, there are no other costs for implementing PKI in embodiments of the invention. Some embodiments therefore provide a zero overhead signing solution. While the embodiments described above provide a public key in a PKI, it is to be appreciated that embodiments can provide a key or a public key in any other situation where secured key delivery is required, such as Secured Sockets Layer (SSL).

The operation of some embodiments will now be described in more detail with reference to figure 1. The arrows show in figure 1 between the DNS server 1 , the client device 2 and the management server 3 represent the communication of data between these components of the system during each step of operation. In this embodiment, the client device 2 is operated by a vendor or file creator which creates a data file 8. The vendor wishes to distribute the data file 8 securely using the PKI implementation. The vendor is an authorised domain controller for a domain name who is authorised to modify the DNS record for the domain name in the DNS. The domain name is, for instance, the domain of the vendor's company. As the keys are created by the organisation or individual and the domain and DNS is also under control of the organisation, another party is unable to create certificates or advertise on their behalf.

The system of some embodiments is protocol independent and allows users or organisations to select a particular signing algorithm. Since the client controls key generation and distribution through DNS they are able to specify the algorithm they wish to use. Some embodiments support all major signing algorithms, such as RSA, ECDSA etc.

In a first step 9, the vendor stores a public signing certificate comprising a public key for the data file 8 as a TXT record as part of the DNS record in the DNS memory of the DNS server 1 . A TXT record is an unformatted record that can carry any text. The TXT record can be formatted so that only specific records are retrieved. In some embodiments, by differentiating each TXT record, a number of different public keys can be used to differentiate between different public certificates in the TXT records. Using the example of divisions in a company, a different selector can be used for each signing division. In the event a key pair is compromised, the use of different key pairs can give granular ability to stop use of a signing pair. In future, each person may have their own DNS based public key for use with embodiments of the invention, giving a digital signing capability to each person for little or no cost.

In a second step 10, the vendor transmits the data file 8 to the management server 3, where it is stored in a memory. The vendor also transmits information identifying the domain linked to the public key associated with the data file 8. The management server 3 checks that the domain is in an allowed list of domains. If the domain is not in a list of allowed domains, the management server 3 rejects the data file 8.

If the domain is in the allowed list of domains held by the management server 3, in a third step 1 1 , the management server 3 requests DNS record information from the DNS server 1 . In a fourth step 12, the DNS server 1 replies with the DNS record information and transmits the DNS record information to the management server 3. In a fifth step 13, the management server 3 sends a request to the DNS server 1 for the public key associated with the domain and the data file 8. In a sixth step 14, the DNS server 1 transmits the public key to the management server 3. The management server 3 uses the public key obtained from the DNS server 1 to verify the signature of the data file 8. If the management server 3 determines that the signature is valid, the management server 3 stores the data file 8.

In a preferred embodiment, the management server 3 computes a cryptographic hash of the data file 8 and stores the hash. A further data file that has an identical hash may then be stored within the management server 3. The hash provides integrity to the system since, in some embodiments, the hash is re-calculated and checked on the management server 3 or the client device once the signature has been verified and decrypted.

Once the management server 3 has verified and stored the data file 8, the management server 3 can act as a repository to deliver the verified data file 8 to client devices. The data file 8 is considered to be a whitelisted data file since the authenticity of the data file has been verified using the PKI implementation of an embodiment of the invention.

In some embodiments, the management server 3 is configured to store a plurality of whitelisted data files that have each been verified as being authentic by accessing a public key or certificate stored by the DNS server 1 . This functionality gives users and organisations the confidence that any and all systems can and should receive only signed, whitelisted files from the management server 3.

A computer system is typically presented with two types of data; functional data and operational data:

• Functional data involves the function of the system. For example, a web server hosting a blog site is there to take in information from the blogger to serve the information to people interested in the blogger's views or experiences.

· Operational data is data that is required to keep the service running in order to perform its function. For example operational data includes operating installs and updates, software installs and updates, firmware updates, configuration updates etc.

Operational data should never be installed on a system if the source and integrity of the data cannot be verified. The management server of some embodiments ensures the integrity of all operational data by signing the operational data at the source and validating the data before delivery to client devices. Once signed, the sender can forward his data to a client device that is configured for use with embodiments of the invention. The system verifies that the data has come from the sender and that the data has not been modified, before the management server presents the data to the client device.

The system of some embodiments ensures that vendors can provide data files to end users securely, while allowing the end users to easily verify the authenticity and origin of the data files.

The system of some embodiments only allows data files from trusted sources to be stored by the management server 3. Client devices communicating with the management server 3 can be certain that data files provided by the management server 3 and verified using the public key provided by a DNS, as described above. This reduces the amount of data that the client device must check since the client device can automatically discard any data that has not originated from the management server 3. Referring now to figure 5 of the accompanying drawings, the system of some embodiments provides complete source to destination validation of data files. The system enables data files 15, such as firmware updates 16, software updates 17, software packages 18 or configuration updates 19 to be signed by vendors 20, with the public key or certificate being stored in the DNS. The management server 3 verifies the data files 15 and stores the data files as whitelisted data files. The management server 3 is configured to provide the verified whitelisted data files to end users 21 who can be confident that the data files are valid and secure since the data files are provided by the management server 3 and verifiable using the public keys stored in the DNS.

Referring now to figure 6 of the accompanying drawings, the system of some embodiments provides a validated chain of trust across an entire supply chain network 22. Vendors 20 sign data files 15 and provide the signed data files 15 to the management server 3. The management server 3 preferably computes a hash 23 for each data file. In some embodiments, the management server 3 is configured to enable data files stored within the management server 3 to be scanned for malware by an external or local malware scanning facility 24. The management server 3 is configured to provide the whitelisted and signed data files, which preferably also been scanned for malware, to client devices or systems 25. The client devices or systems 25 can take many different forms and be accessible via wired or wireless communication methods or via hardware which is transported physically into an air-gapped system.

Referring now to figure 7 of the accompanying drawings, the system of some embodiments is configured to reduce the noise or exposure to data files experienced by client devices by storing signed data files from a plurality of authorised vendors 26. A client device only needs to communicate with the management server 3 to receive whitelisted data files provided by the plurality of vendors 26.

In some embodiments, the management server 3 provides a cloud service over the Internet that acts as a validation or termination point for data files. The cloud service of some embodiments minimises the operational impact on end client devices for validating data files, for instance when accessing software updates. Some embodiments are configured to enable users and organisations to manage the key lifecycle easily. The system of some embodiments is configured to enable a user or organisation to modify a DNS record to set its Time To Live (TTL). By setting the TTL the user or organisation is able to have granular control of the frequency the certificate is checked. For example, a TTL set at 60 seconds forces domain resolvers to clear their cache every minute. The user or organisation can remove the DNS record and have the key disappear in one minute, effectively revoking the certificate.

In some embodiments, the DNS is configured to enable a client device to authenticate data provided by the DNS. This is preferably done by configuring the DNS to use domain name system security extensions (DNSSEC). DNSSEC secures the DNS records by using a PKI infrastructure in the back end of the DNS to sign and organise DNS records. This ensures that if the DNS records are checked by a receiving party the records are valid and that they have not been modified. The DNSSEC implementation of some embodiments is invisible to client devices and is implemented on DNS resolvers. DNSSEC makes the system resistant to a DNS spoofing or poisoning attack where false information is introduced by a malicious party into a DNS record to divert a user to the malicious party's computer instead of the computer or IP address that was originally intended to be linked to the domain. While some embodiments operate by transmitting clear (unencrypted) text between a client device and the DNS, in other embodiments the system is configured to encrypt data transmitted between a client device and the DNS. In some embodiments, the encryption is carried out using a DNSCrypt protocol. The encryption of data between a client device and the DNS minimises the risk of the system being vulnerable to a man in the middle attack where a malicious party relays and potentially alters data communicated between a client device and the DNS.

The system of some embodiments is configured to provide a public key or certificate for signing. In other embodiments, the system is configured to provide a public key for encryption. The system of some embodiments allows for users to verify the proof of origin of a data file. This is implemented by a supplier creating a private/public key pair and signing the data file with the private key to provide proof of origin. The system of some embodiments enables a user or organisation to scale up their secure distribution of data easily without any additional overhead because the user or organisation advertises their public signing certificates via the DNS. No additional infrastructure is required. As each individual user or organisation is responsible for the advertising of their signing public key, there is no additional overhead on the verifying party

The signing of the whitelisted file by the sending party, as mentioned previously, provides proof of origin and integrity. In the event that there is an issue with the signed file the signed file and the issue can be attributed back to the sending party. The onus is therefore on the sending party to provide files that are signed correctly.

In some embodiments, the system is configured to provide non-repudiation. As with signing, non-repudiation is supported in some embodiments by the system signing a receipt with the original receiver's private key.

One time signing

The system of some embodiments is configured to provide one time signing (OTS) functionality. In these embodiments, the system is configured to create a one time signing key pair and to sign each data file individually. This provides a greater granularity in validation and control of the data files. A key is only used once so if the key is compromised and reused, the system blocks the use of the key. If a data file needs to be withdrawn from service for any reason the system is configured to remove the corresponding public key from the DNS. If the data file is then checked by the system contacting the DNS, the data file fails validation. This implementation of some embodiments therefore effectively functions as a public key whitelist.

In some embodiments, signing public keys are only advertised by DNSSEC protected DNS records. By only allowing valid public keys to be advertised by DNSSEC enabled DNS records, and also only pulling down public keys from the same controlled source, public keys can be controlled. Furthermore, having one source of public keys and by mapping a single key pair per data file enables the system to perform an audit of allowed data files. The audit is performed by a user checking the DNS records for any additions. If an additional record has been added to the DNS records that isn't allowed then the addition can be flagged as a potential security risk.

The system of some embodiments enables granular processing of signed data. The one time signing implementation of some embodiments allows additional metadata to be added (via the manifest file). At present files, once validated, are processed into their own folder sorted by ID. Once One Time Signing is applied then each ID is unique so a system description will be a field in the manifest. This enables each system or piece of software to be separated. A device would only accesses updates from their own folder which reduces the risk of incorrect updates being presented to the wrong device/service.

The one time signing (OTS) functionality of some embodiments overcomes many of the problems experienced by conventional PKI where there is often a one to many mapping with one signing key being used for multiple files. Revocation of the key pair results in all associated signatures for the multiple files being invalidated. By contrast, the one time signing solution of some embodiments maps each key to only one data file, so the revocation of one key pair does not affect multiple files. Unlike conventional PKI, the system of some embodiments is not compromised if a private key is stolen because the private key can only be used once. The system of some embodiment is not vulnerable to the same level of exploitation that is possible when a private key is stolen as in conventional PKI, for instance when private keys were stolen to sign the Stuxnet code.

In some embodiments, if a private key is stolen then it is useless as it can only be used once. If a master key is stolen and a one time key pair created then the pubic key still needs to be advertised via the DNSSEC protected DNS domain. If both the private key and the master key are stolen then monitoring DNS record will provide a mechanism to detect/alert that a new record has been added allowing for easy removal. The system of some embodiments enables a company to detect when its keys have been stolen and to detect when other files are being signed.

A method of some embodiments for creating a one time signing key pair will now be described with reference to figures 8 and 9 of the accompanying drawings.

The system starts with a new data file 27 and creates a key pair for the data file 27. The system then creates a manifest including a unique identifier (ID), domain, file name and ID for processing. The system creates a zip file and manifest, signs the zip file and the manifest and creates a data package with the unique ID. The system then destroys the private key.

At the point of creating the signing key pair, the system sends the unique ID, domain and signature to the management server 3. The management server 3 checks whether the unique ID exists in the DNS record for the domain. If the check identifies that the unique identifier already exists in the DNS record, the management server 3 provides this feedback to the key pair generation module.

If the unique identifier does not exist in the DNS record for the domain, the management server 3 adds the unique ID and a hash from the signature to a local database within the management server 3. The management server 3 then requests the DNS record for the domain with the unique ID from the DNS. The management server 3 checks whether the unique ID exists in the DNS record. If the unique ID exists in the DNS record then the management server 3 returns this result to the key pair generation module which in turn generates a new key pair.

If the unique ID does not exist in the DNS record then the management server 3 creates a new unique ID in the DNS record with the public key and any associated metadata.

Referring now to figure 10 of the accompanying drawings, the structure of a data package 28 created using a system of some embodiments comprises a zipped or otherwise compressed data file 29 and a signature 30 of the zipped data file 29. The zipped data file 29 comprises file data 31 and a manifest text file 32.

The manifest text file 32 comprises a domain indicator 33, the unique ID 34, and ID for processing 35, a file name 36 and a signed/encrypted indicator 37.

The system is configured to verify the data package structure 28 by unzipping or decompressing the zipped data file 29 and also separately storing the original zipped data file 29. The system accesses the manifest text file 32 and uses the domain identifier 33 to retrieve the public key from the DNS. The system uses the public key to verify the signature 30 of the original zipped data file 29. If the verification of the signature fails then the system moves the zipped data file 29 to a quarantined memory. If the signature is verified successfully then the system enables the data file 31 and the information in the manifest text file 32 to be used by a client device.

Some embodiments of the invention will now be described with reference to specific use cases. It is however, to be appreciated that these are not the only use cases for embodiments of the invention.

1 ) Internet of Things (loT):

Referring to figure 1 1 of the accompanying drawings, an loT device 38 has domain information embedded into the device. Any/all updates to the loT device would be verified using the DNSPKI method of an embodiment of the invention:

1 . A sending party signs a data file with a private key for delivery to an loT device.

2. The loT device receives the data file, looks up domain information and retrieves the public key from the DNS to verify the sender and the integrity of the data file.

3. As well as SSL, the public/private key can used to hold keying data to set up encrypted transport.

4. A response using the DNSPKI method from the loT device using the public key provides proof of receipt non repudiation. 2) Supply chain:

In some embodiments, every data file supplier would register a domain and provide a public key.

1 . Upon delivery of a data file, the recipient performs a DNS lookup on the supplier's domain and retrieves the public key.

2. The public key is used to decrypt a digital signature of the data file to verify the sender and the integrity of the data. 3. Proof of receipt non-repudiation may be provided by signing the data with the private key of the recipient.

4. The digital signature is sent to the sender. The sender performs a DNS lookup to retrieve the public key of the recipient domain.

5. The public key is used to decrypt the signature. If the sender's hash and the recipient hash match, the supplier has proof of receipt.

3) Forensic timeline:

Referring to figure 12 of the accompanying drawings, the system of some embodiments is configured to encapsulate a digital signature as the data file passes through each provider.

A product or application may pass through multiple providers/suppliers before reaching the recipient. By encapsulating each signature along the path, the recipient maintains a full supply chain list.

4) Identity Management/Services:

Given the global reach of DNS the method and system of some embodiments has the ability to provide identification services. By securing the private key of a user/organisation, and potentially adding other factors of authentication, the method and system of some embodiments can be used to verify the identity of the user/organisation.

5) SSL:

The ability of embodiments of the invention to serve public keys over the internet can be used to provide public keys for browser and internet based SSL services. For example the method and system of some embodiments could be used for dynamic keying for VPN traffic. The public key can be retrieved and then used to set up encrypted transport VPN to destination. The DNS record could include this information. The VPN endpoint could pull the information from the DNS record before dynamically setting up a tunnel to the recipient or target system. 6) 2 way authentication:

Current setups using SSL usually operate via a 1 way trust as typically servers need to be able to communicate with anyone trying to connect. The method and system of some embodiments enables a simplified identification of parties connecting to services enable 2 way (mutual) authentication.

7) Digital Forensics:

The method and system of some embodiments enables an investigator to sign data at source and a receiver anywhere in the world can verify the authenticity and integrity

8) Web content signing:

The system and method of some embodiments enables any web content to be verified against a DNS supplied certificate, allowing any and all content to be verified in real time.

9) Document security/watermarking:

The system and method of some embodiments enables documents signed by a private key to be verified in real time, thereby checking the security of a document.

10) Code signing:

As software is developed, the system and method of some embodiments enables code to be easily signed by any developer to show proof of origin and integrity.

11 ) Mobile device software signing:

The system and method of some embodiments enables a software developer to sign code for any device. Rather than having one central repository for code distribution, a verified developer can sign their software and the device manufacturer could allow use of the software by in response to successful validation of the software by checking the DNS record. If a developer was no longer allowed to produce software then the DNS record can be removed and the developer blocked. Web-verify

Referring now to figure 13 of the accompanying drawings, the system of some embodiments comprises similar components to the embodiments described above. However, in the system of this embodiment the management server 3 is configured to operate as a central broker handling communication from the client and then either storing data itself, in both itself and the DNS, only in the DNS or via another distributed database or technology, such as the blockchain.

In use, an organisation, person or entity signs a data file in the manner described above. The system provides a user interface 39, preferably in the form of a web page, which is configured to enable a user 40 to upload a data file 41. For instance, the system is configured to provide a web page with a predefined area of the page configured to trigger the upload of the data file 41 when the data file 41 is dragged onto the predefined area or in response to the predefined area being clicked by the user. The user interface is configured to send information identifying the data file 41 to the management server 3 (the central broker) to verify which in turn replies with the appropriate response.

Use cases for the web-verify embodiments of the invention include, but are not limited to:

Corporate website:

An area on a corporate web page can be reserved for customers and clients who have received a document or file from a company to simply drag this file onto the page and receive verification that the company was the source of the file/document/invoice/software/patch etc. In this case, only the signing domains registered to the company would be checked against the data file. General checking:

In some embodiments a general website or other user interface displays an area on which a user can select or drag and drop a file so that the user can check the origin of a file and its integrity. In some embodiments the upload of a data file is automated.

Verification of data and products

The system and method of some embodiments is configured to verify the authenticity of data files using cryptographic hashes of the data advertised via DNSSEC enabled DNS records. This concept is illustrated in figure 14 of the accompanying drawings. The system and method of some embodiments therefore provides a zero overhead signing solution. In some embodiments the verification data can be derived from a unique or substantially unique identifier that identifies a physical item. In these embodiments, a hash value is preferably computed from the identifier.

In the system and method or some embodiments, any data can be hashed and verified in the same way. The same verification functionality can be used with a device or product can be identified by a combination of information about itself and combined into data that is advertised via DNSSEC enabled DNS records in the manner described above. The verification functionality of some embodiments addresses the problem of forgery or counterfeit items that are a major issue for companies and customers across the world. Embodiments address this problem by providing a mechanism for verifying the authenticity of products, devices or other physical items. This is achieved by the system and method of some embodiments digitally signing a unique identifier (ID) of a product, device or other physical item or a digital representation of a product. The unique identifier or digital representation of a product preferably comprises any combination of data that results in the data being unique. The signature generated by an embodiment is made available to the public via a secure service. In some embodiments, the signature is made available via a secure service in the form of DNS and configured to be accessed using a software application. A user can validate the authenticity of a product throughout the entire supplying chain by obtaining the signature from the secure service. In other embodiments the system and method is configured to use non-unique information that identifies a product, device or other physical item. However, those skilled in the art will appreciate that this implementation is not as effective as the preferred embodiment which uses a unique identifier. The system and method is preferably configured to utilise and track any identifiable information for verification purposes. The identifiable information is for example, but not limited to, information indicating geo-location, type, make, colour, weight, size, Unique Identifier, Serial number etc. The following examples are just some examples of use cases for the verification functionality of embodiments of the invention.

Example 1 : High value products

High value, low volume luxury items such as watches, handbags are often copied and supplied on the black market. An embodiment of the invention enables a consumer to verify and guarantee the authenticity of a product prior to purchase. The verification functionality enables manufacturers or brands to protect their intellectual property, while decreasing illegal activities in counterfeit goods.

Example 2: Pharmaceuticals Illegal copies of drugs can potentially be very dangerous. Globally accessible verification information would enable a customer to use, for example, an application on a smart phone to verify the authenticity of a drug. The maker of a drug would place unique information the secure storage provided by an embodiment of the invention (e.g. in a secure DNS record). At the point of purchase or at any point along the supply chain, a user can use the verification functionality of an embodiment of the invention to verify that the drug is authentic. Example 3: Consumables - ink cartridges

To aid in the identification of cloned ink cartridges, unique information associated with an ink cartridge is stored securely by an embodiment of the invention (e.g. in a secure DNS record). The cartridge can be verified as authentic upon insertion into a printer or via a device, such as a smartphone, by accessing the unique information via an embodiment of the invention.

Example 4: Products comprising chemical compounds

Some embodiments are configured to verify the authenticity of a product that combines multiple chemical compounds that vary slightly in different batches of the product (e.g. oil, gas, etc.). The particular composition of the chemical compounds makes each batch of the product unique or substantially unique.

An embodiment of the invention utilises this unique or substantially unique information by signing or representing the information as a cryptographic hash.

The authenticity of a product can be verified by measuring the composition of chemical compounds in the product, calculating a cryptographic hash from the composition information and comparing the hash with a has advertised via an embodiment of the invention.

In some embodiments, the information used to provide uniqueness can be a combination of physical attributes but can also be stored on a variety of data identifiers. Examples of identifiers for use with embodiments of the invention, include, but are not limited to:

1 ) Radio frequency identification (RFID) tags

2) Holograms

3) Labels

4) Chemical signatures

In the examples listed above, the identifiers are digitally signed by an embodiment and the signature is preferably placed under the control of the product manufacturer.

The method and system of some embodiments will still function with non- signed identifiers but will not provide a definite confirmation of uniqueness due to the ability to clone the identifiers.

In the event a product needs to be removed from service or circulation, the product identifier can be removed from the secure storage in an embodiment. If a customer checks the authenticity of the product, it will no longer show as valid. In the same way, a store or reseller can check and not have the product shown as valid. This allows vendors or manufacturers to withdraw products remotely if required.

Referring now to figure 15 of the accompanying drawings, a system and method of some embodiments comprises many of the same components and functionality as the embodiments described above but is configured to verify the authenticity of a data file in the form of a software application 42. In these embodiments, the system computes a hash of at least part of the data of the software application 42, with the hash providing a unique identifier for the software application 42. The hash is computed using a hash algorithm selected from, but not limited to MD5 or sha256. The computed hash provides a software tag (SWID) for the software application 42. The system stores the SWID tag for the software application 42 securely in a repository, as described above for the other embodiments. For instance, the SWID tag is stored in a secured DNS record. A user can verify the authenticity of the software application 42 by computing a hash from the data of the software application 42 and querying the SWID tag repository for the computed hash. If the computed hash is present in the SWID tag repository then the user can be certain that the software application 42 is authentic.

In some embodiments, the software application 42 is configured to only execute in response to a successful verification of the authenticity of the software application 42 using an embodiment of the invention. In this way, an embodiment of the invention can make continuous monitoring possible for software applications to avoid or minimise the risk of unauthorised software applications executing on a device.

Whitelisting

The system and method of some embodiments if configured to provide a community whitelisting service which only allows known good files or data into an environment. The concept of community whitelisting has been historically difficult to implement due to the difficulty in populating the whitelist. The system and method of some embodiments addresses this problem. The system and method of some embodiments provides a mechanism for the creators of files or data to store hashes of known good files securely. The hashes are preferably stored in DNS records, as described above. The DNS records may or may not be secured DNS records (DNSSEC). A user can easily verify the validity of a file or data by comparing a hash of the file or data with a hash stored by the system. If the computed hash is stored by the system then the user can be certain that the file or data is authentic. Referring now to figures 16 and 17 of the accompanying drawings, the system of some embodiments comprises a management server 3 of the type described above, which is also referred to as a UMS. The system further comprises a broker server 43 which is configured to communicate with the management server 3. The broker server 43 is configured to communicate with a DNS one.

The system is configured to enable vendors A, B, etc. to provide data files 44 to end users 45 and to permit the end users 45 to verify the authenticity of the data files 44.

The method used with an embodiment of the invention for a vendor to register a data file 44 with the system will now be described with reference to figure 16.

The vendor starts by computing a hash value or hash from the data file 44 using a hashing algorithm and a hashing module, such as MD5. The system then sends the computed hash to the DNS 1 , preferably in the form MD5@domain.com (sha256+filename). The hash is stored securely in a DNS record in the manner described above.

In this embodiment, the identifier is a MD5 hash value but in other embodiments the MD5 hash value is replaced by any other repeatable identifier. It is to be appreciated that, any digest value calculated by cryptographic or non-cryptographic means may be used in embodiments of the invention instead of a hash value.

In some embodiments, the identifier is selected using a hashing technique selected from a group comprising, but not limited to, SHA1 , SHA-2, SHA-3, CRC-8, CRC-16, CRC-32 or CRC-64.

For example, in some embodiments a CRC32 value is calculated for a file and used to retrieve a number of possible candidates hash values. The system and method then isolates the correct hash value by obtaining the hash value from a record in the storage system (DNS, SQL or blockchain).

The system sends the hash information, preferably in the form of MD5@domain.com to the broker server 43. The broker server 43 looks up MD5@domain.com and pulls back the sha256 and filename to prove the record is valid.

The broker server 43 then adds the hash (MD5), sha256, domain and filename to a database stored by the broker server 43. The broker server 43 preferably also stores a predetermined TTL for the record for valid sha256.

Once the hash records have been stored securely by the system, for instance in the DNS with one hash value being stored in a DNS record for each file, a hardware or software client can look up the hash of a file, calculate the hash (MD5) of a file and query the DNS using the format MD5@domain.

The lookup can be directly from the software or hardware client or via the broker server 43, as described below.

Figure 17 of the accompanying drawings illustrates an example DNS hash lookup. The lookup method is summarised as follows:

1 . The management server 3 (UMS) tries to retrieve any metadata from the file. i.e. company name, signing name etc. to be used for identification of the domain holding the hash record.

2. The management server 3 sends the hash (MD5) and allowed domain list to the broker server 43.

3. The broker server 43 looks up MD5@ all allowed domains locally, (e.g. flat file, database etc.)

4. If a match is found then the management server 3 looks up existing sha256 and checks the TTL (Time To Live of DNS record) 5. If TTL is valid then the broker server 43 responds to the management server 3 with MD5@domain.com (sha256+filename)

6. If TTL has expired then the broker server 43 sends DNS lookup to known DNS domain to retrieve SHA256 and filename.

7. If no entry in the database then send a DNS request to all allowed domains (sent by management server 3)

8. If a valid DNS response with sha26 and filename is retrieved then respond to UMS and enter in database

9. The system is preferably configured to permit the lookup to be carried out via an API to a third party hash database

Third party API

As hash to domain mappings are retrieved by one of the methods described above they are added to the database of the broker server 43. This, in time, will provide a hash/domain resource which can be presented to third parties. A dynamic whitelisting capability of the same concept can be applied to a variety of different situations. For example, but not limited to:

• A website where, for example, non-active content could be whitelisted and verified when loaded onto a host therefore validating the content.

• Source code. For example, source code can be uploaded to a repository and the hash of the code would be advertised via DNS to allow instant global verification.

• Patches. For example, any vendor releasing a patch would advertise the hash of the patch in their DNSSEC protected DNS zone/record, giving clients an instant method for verifying code.

• Documents. For instance, a new version of a document would place its hash in a domain which would be removed and replaced if updated therefore invalidating previous versions

• loT. For example, updates and data being supplied by or to loT devices can be hashed and advertised by DNS in order to be verified. In some of the embodiments described above, the signing information for a file is stored in the DNS, thereby avoiding the need for files to be repackaged. The mapping of the file to the DNS record is done by calculating the hash of the file and appending to the domain for lookup. This also allows lookup against DNS at any point in the lifecycle of the file. This is in contrast to traditional signing methods which require the signing information and the file to be packaged together for verification later. Once unpackaged, the signing link is gone.

The method and system of embodiments of the invention is file and operating system agnostic. Since the signing information is separate to the file, transport mediums (email, social media, chat etc.) are irrelevant.

In some of the embodiments described above, the storage system is a DNS server but it is to be appreciated that any other storage system with a security function may replace the DNS server in other embodiments. For instance, in some embodiments, the storage system is a database in a secure broker server.

In other embodiments, the storage system is a distributed database or blockchain which is configured to store verification data or signing data. A blockchain is a distributed database that maintains a continuously growing list of records, called blocks, secured from tampering and revision. In embodiments that have a storage system in the form of a blockchain, a record is created by a broker server and then entered into the blockchain using a blockchain client. When verifying, a client would request the record from the broker server who would in turn check for the record in the blockchain. The replicated mesh/setup of the blockchain prevents unauthorised tampering of the record so that the record is stored securely. In some embodiments, the method is implemented in executable instructions that are stored on a computer readable medium. In some embodiments the executable instructions form part of a plugin or API module which is configured to provide the same signing and verification functionality as the embodiments described above to an associated executable application.

In some embodiments the method is implemented in executable instructions that are configured to provide signing and verification functionality to one or more of:

• A mail client, such as, but not limited to, Microsoft Office®, Mozilla Thunderbird®, OSX Mail®, etc.

• A social media application or platform, such as, but not limited to, Facebook®, Skype®, WhatsApp®, Facetime®, etc.

• A cloud file storage application or platform, such as, but not limited to, Dropbox®, Google Drive®, OneDrive®, iCIoud® etc.

• A collaboration application or platform, such as, but not limited to, Confluence®, SharePoint®, Slack®, Asana®, etc.

In some embodiments, the system and method is configured to allow the signing in one application or platform to be verified in another application or platform and preferably also vice versa.

Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of some embodiments of the present invention could be embodied in software, firmware, and/or hardware, and, when embodied in software, can be downloaded to reside on and be operated from different platforms used by a variety of operating systems. The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium. Furthermore, the computers and/or other electronic devices referred to above may include a single processor or may be servers or architectures employing multiple processor designs for increased computing capability.

The algorithms and executable instructions described herein are not inherently related to any particular computer, virtualised system, or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialised apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent from the description provided herein. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references above to specific languages are provided for disclosure of enablement and best mode of the present invention. In various embodiments, the present invention can be implemented as software, hardware, and/or other elements for controlling a computer system, computing device, or other electronic device, or any combination or plurality thereof. When used in this specification and the claims, the term "comprises" and "comprising" and variations thereof mean that specified features, steps or integers and included. The terms are not to be interpreted to exclude the presence of other features, steps or compounds. The features disclosed in the foregoing description, or the following claims, or the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for attaining the disclosed result, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.

Claims

1 . A computer implemented verification method, the method comprising: providing verification data for verifying the authenticity of a data package, the verification data being identified by an identifier;

storing the verification data in a storage system, the storage system being configured to prevent an unauthorised party from modifying the verification data;

receiving a request for the verification data from a client device, the request comprising at least the identifier;

providing the verification data to the client device in response to the request; and

verifying the authenticity of a data package at the client device using the verification data.

2. The method of claim 1 , wherein the identifier comprises a hash value of the data package.

3. The method of claim 2, wherein the method comprises using a hashing algorithm to calculate the hash value of the data package.

4. The method of claim 3, wherein the hashing algorithm is a MD5 hashing algorithm.

5. The method of any one of the preceding claims, wherein the data package is a software data file.

6. The method of any one of claims 1 to 4, wherein the data package is a substantially unique identifier which identifies a physical item.

7. The method of claim 6, wherein the substantially unique identifier is a hash value computed from data linked to a physical item.

8. The method of any one of the preceding claims, wherein the method further comprises:

revoking the verification data by preventing access to the verification data in the storage system or by removing the verification data from the storage system.

9. The method of any one of the preceding claims, wherein the verification data is a public key for use in a public key infrastructure (PKI).

10. The method of any one of the preceding claims, wherein the storage system is secured using a security function to prevent an unauthorised party from modifying the verification data.

1 1 . The method of claim 10, wherein the storage system is a blockchain.

12. The method of any one of the preceding claims, wherein the storage system is a memory in a domain name system (DNS) and the method comprises storing the verification data in a DNS record of the DNS.

13. The method of claim 12, wherein the method further comprises:

preventing an unauthorised party from modifying the DNS record.

14. The method of claim 12 or claim 13, wherein the method further comprises:

comparing a further public key with at least one public key stored in the DNS record, wherein

if the further public key matches a public key stored in the DNS record the further public key is authentic, and

if the further public key does not match a public key stored in the DNS record the further public key is not authentic.

15. The method of any one of claims 12 to 14, wherein the DNS is secured using domain name system security extensions (DNSSEC).

16. The method of any one of claims 12 to 15, wherein the method further comprises:

encrypting data sent between the client device and the DNS.

17. The method of claim 16, wherein the DNS is configured for encrypted communication with the client device using a DNSCrypt protocol.

18. The method of any one of claims 12 to 17, wherein the method further comprises:

storing, in the DNS, an indication of a signing algorithm to be used with verification data stored in the DNS record.

19. The method of any one of claims 12 to 18, wherein the method further comprises:

storing, in a DNS record, a time to live (TTL) value for the verification data stored in the DNS record; and

providing the TTL value to the client device with the verification data, the TTL value indicating a time period after which the verification data is discarded by the client device.

20. The method of any one of claims 12 to 19, wherein the method further comprises:

providing a management server which is configured to communicate with the DNS;

receiving a data file at the management server;

verifying the authenticity of the data file at the management server by: requesting verification data from the DNS which corresponds to the data file; and using the verification data to verify the authenticity of the data file;

wherein if the data file is verified as being authentic the method comprises storing the data file as a whitelisted data file in a memory of the management server and if the data file is not verified as being authentic the method comprises discarding the data file.

21 . The method of claim 20, wherein the method further comprises:

computing a hash value from a data file stored in the memory of the management server; and

storing the hash value with the data file in the memory of the management server.

22. The method of claim 21 , wherein the method further comprises:

computing a hash value from a further data file and comparing the computed hash value with a hash value stored in the memory of the management server to verify the authenticity of the further data file.

23. The method of any one of claims 12 to 22, wherein the method further comprises:

checking the number of DNS records stored in the DNS memory; and outputting an alert if there are a greater or fewer number of DNS records stored in the memory than a predetermined expected number of DNS records.

24. The method of any one of the preceding claims, wherein the method further comprises:

encrypting data communicated between the client device and the storage system using the verification data.

25. The method of any one of the preceding claims, wherein the method further comprises: sending a receipt data file from the client device to the storage system, the receipt data file being signed by the client device using key for non- repudiation.

26. The method of any one of the preceding claims, wherein the method further comprises:

generating a one-time signing key pair comprising a public key and a private key;

providing the public key to the client device; and

removing the public key from the storage system to prevent the storage system from re-issuing or providing access to the same public key.

27. A computer readable medium storing instructions which, when executed by a processor, perform the steps of the method of any one of the preceding claims.

28. A verification system comprising:

a storage system storing verification data, the verification data for verifying the authenticity of a data package and the verification data being identified by an identifier, wherein the storage system is configured to prevent an unauthorised party from modifying the verification data, and wherein the storage system is configured to provide the verification data to a client device in response to a request from the client device that comprises at least the identifier such that the client device can use the verification data to verify the authenticity of a data package.

29. The system of claim 28, wherein the identifier comprises a hash value of the data package.

30. The system of claim 29, wherein the system comprises a hashing module which is configured to use a hashing algorithm to calculate the hash value of the data package.

31 . The system of claim 30, wherein the hashing algorithm is a MD5 hashing algorithm.

32. The system of any one of claims 28 to 31 , wherein the data package is a software data file.

33. The system of any one of claims 28 to 31 , wherein the data package is a substantially unique identifier which identifies a physical item.

34. The system of claim 33, wherein the substantially unique identifier is a hash value computed from data linked to a physical item.

35. The system of any one of claims 28 to 34, wherein the system is configured to revoke the verification data by preventing access to the verification data in the storage system or by removing the verification data from the storage system.

36. The system of any one of claims 28 to 35, wherein the verification data is a public key for use in a public key infrastructure (PKI).

37. The system of any one of claims 28 to 36, wherein the storage system is configured to provide a security function to prevent an unauthorised party from modifying the verification data.

The system of claim 37, wherein the storage system is a blockchain.

39. The system of any one of claims 28 to 38, wherein the storage system is a memory in a domain name system (DNS) and the system is configured to store the verification data in a DNS record of the DNS.

40. The system of claim 39, wherein the system is configured to prevent an unauthorised party from modifying the DNS record.

41 . The system of claim 39 or claim 40, wherein the system is configured to compare a further public key with at least one public key stored in the DNS record, wherein

if the further public key matches a public key stored in the DNS record the system is configured to indicate that the further public key is authentic, and if the further public key does not match a public key stored in the DNS record the system is configured to indicate that the further public key is not authentic.

42. The system of any one of claims 39 to 41 , wherein the DNS is secured using domain name system security extensions (DNSSEC).

43. The system of any one of claims 39 to 42, wherein the system is configured to encrypt data sent between the client device and the DNS.

44. The system of claim 43, wherein the DNS is configured for encrypted communication with the client device using a DNSCrypt protocol.

45. The system of any one of claims 39 to 44, wherein the DNS is configured to store an indication of a signing algorithm to be used with verification data stored in the DNS record.

46. The system of any one of claims 39 to 45, wherein the DNS is configured to store a time to live (TTL) value for the verification data stored in the DNS record, and the DNS is configured to provide the TTL value to the client device with the verification data, the TTL value indicating a time period after which the verification data is discarded by the client device.

47. The system of any one of claims 39 to 46, wherein the system further comprises:

a management server which is configured to communicate with the DNS, the management server being configured to receive a data file and to verify the authenticity of the data file by:

requesting verification data from the DNS which corresponds to the data file; and

using the verification data to verify the authenticity of the data file;

wherein if the data file is verified as being authentic the management server is configured to store the data file as a whitelisted data file in a memory of the management server and if the data file is not verified as being authentic the management server is configured to discard the data file.

48. The system of claim 47, wherein the system is configured to compute a hash value from a data file stored in the memory of the management server and store the hash value in the memory of the management server.

49. The system of claim 48, wherein the system is configured to compute a hash value from a further data file and compare the computed hash value with a hash value stored in the memory of the management server to verify the authenticity of the further data file.

50. The system of any one of claims 38 to 49, wherein the system is configured to check the number of DNS records stored in the DNS memory and to output an alert if there are a greater or fewer number of DNS records stored in the memory than a predetermined expected number of DNS records.

51 . The system of any one of claims 28 to 50, wherein the system is configured to encrypt data communicated between the client device and the storage system using the verification data.

52. The system of any one of claims 28 to 51 , wherein the system is configured to send a receipt data file from the client device to the storage system, the receipt data file being signed by the client device using key for non-repudiation.

53. The system of any one of claims 28 to 52, wherein the system is configured to generate a one-time signing key pair comprising a public key and a private key, provide the public key to the client device and remove the public key from the storage system to prevent the storage system from re-issuing or providing access to the same public key.