Paper— A Credible Food Traceability System Based on Domain Name System Security Extensions A Credible Food Traceability System Based on Domain Name System Security Extensions

— Food safety has drawn worldwide attention because of its enormous impact on human health and social stability. Although traceability systems based on Internet of Things (IoT) can improve the visibility of the food supply chain, the trust service is necessary to ensure the data origin and data integrity. This paper proposes a food traceability system supported by a trust service based on Domain Name System Security Extensions(DNSSEC). A DNSSEC-enabled traceability system is implemented for food safety in China. In the traceability system, the master data and event data of the products is stored in distributed databases owned and managed by the enterprises respectively in the supply chain. Enterprise oriented Internet of Things Information Service (iotIS) is an important component of the distributed traceability system. A trust service for the Internet of Things, iotTS, is proposed to guarantee the data integrity. With this service, it can be ensured that the information stored in the enterprise database is original and has never been manipulated. Lightweight public keys are distributed based on the DNSSEC in this solution. Compared with the existing solutions, the proposed solution has better scalability and credibility.


Introduction
Food safety is a worldwide issue and it has garnered concerns from governments and the society because of its adverse effects to public and household health and interests [1]. Although food safety issues have led to fewer fatalities than those caused by other issues, such as cancer or traffic accidents, traditional and social media can enlarge the social hazards caused by food safety issues. Food safety issues affect the happiness of the people, increase the management cost of governments, evoke the distrust of food safety, and jeopardize the development of both the economy and soci-claimed enterprise, and the product data has never been manipulated during transmission. Thus, the responsibility of the food safety can be oriented to the producing enterprise.
The remainder of this paper is organized as follows. We briefly review the background of the trust service on information reliability and the related works in Section 2, and in Section 3, a traceability system framework for food safety in China is proposed. Section 4 introduces the architecture of the proposed trust service, including the essential problems and the solutions. Performance testing of the trust service is presented in Section 5. We give a conclusion and introduce the future work in Section 6.

Related Works
In the food tracking and tracing system based on the IoT technology, the master data and event data of the products are stored in the iotIS database of the enterprise providing the information. When the clients, such as the downstream enterprises in the supply chain, the supervisors and the customers, query the food product information, it is necessary to ensure that the information is original and has never been manipulated.
The information stored in distributed databases of enterprises is vulnerable to external attack and internal manipulation. The manipulation on the information in the databases can be classified into the following cases: 1. The enterprise modifies the information in the iotIS deliberately. 2. The iotIS is attacked by the hackers, and the information in storage is manipulated or deleted maliciously. 3. The iotIS fails because of hardware breakdown, interrupted storage service, or lost information.
The latter two cases can be prevented by adding redundant resources, multiplying backup or enhancing the system security. While for the first case, it is hard to prevent the enterprise from manipulating the information by itself. For instance, assume that there is a quality issue with the material for a batch of food product. While the enterprise manipulates the information about the material in its own iotIS to avoid the product from being called back and reduce the loss. The customers, downstream enterprises and even the supervisors cannot get the original food information, leading to the spread of the food safety trouble. In the cases similar to this instance, the trust service of food information is necessary.

GS1 e-Pedigree
In the year of 2007, GS1 proposed the e-Pedigree of version 1.0 [6] to solve the anti-manipulation issue during the transmission of drugs. The upstream and downstream enterprises in the supply chain compare the information protected by the digital signa-ture in the e-Pedigree with the actual products and receipts to verify if the receipts and the e-Pedigree are reliable.
In the next step, the research on the e-Pedigree and the information reliability converges in the realization, optimization and content extension of them: In 2007, a distributed e-Pedigree architecture was proposed. The pedigree information is saved in EPCIS and the complete pedigree is obtained by searching step-bystep [7].
In 2011, an e-Pedigree system for agricultural products production and circulation is proposed [11]. The key information of agricultural production and circulation is saved in the e-Pedigree and is signed to ensure the data not being manipulated.
In 2012, Korea Industrial Strategic Technology Development Program conducted a comparison of 6 e-Pedigree deployment plans and decided to use the e-Pedigree in the drug distribution regulation [12][13]. This program extended the pedigree content based on the GS1 e-Pedigree standard including the temperature and humidity parameters that have to be monitored in the cold chain transport, thus providing the reliable data for the drug safety regulation.
However, there are some limits for the e-Pedigree using for iotIS data protection for food safety.
• e-Pedigree can only prove the data stored in it is not modified or counterfeited, but lots of data is stored in the iotIS database and the e-Pedigree can't prove its integrity. The extended functions of the e-Pedigree XML can add more food safety related information that is stored in the iotIS. In reference paper [11], cold chain sensor data of temperature and humidity is added in iotIS. However, this way is different from our original intention because the e-Pedigree will become a huge centralized database and lead to the difficulties of maintaining. We intend to make a distributed deployment and clear the responsibility of the data subject and decentralize access pressure. Compared with the information in the iotIS database, the information in e-Pedigree is limited. • As to the GS1 e-Pedigree standard, public key distribution must conform to the X.509 standard. This means that every enterprise engaged in the food safety IoT must apply for public key certification to the CA (certification authority). The CA can authenticate the public key when the e-Pedigree is verified and signed. This method is difficult for the small and medium-sized food production and circulation enterprises, and to apply and use the e-Pedigree is also too complicated.

TPA (Third Party Auditor)
TPA is generally used for the data integrity verification in remote or cloud storage [14][15]. The file is separated into blocks, and whether it has been manipulated is verified by PDP (Provable Data Possession) and POR (Provable Data Possession) methods. The research in this region includes reducing the authentication consumption and privacy protection for the users' data.
However, it is not appropriate to treat the iotIS as cloud storage and perform information verification for the iotIS directly with TPA. There are some differences between iotIS and cloud storage. The PDP and POR methods used for data integrity verification for cloud storage are more suitable for static data with various patterns. Since the data in iotIS is changing with single pattern, it is reasonable to take the method of TPA as a reference, and conduct the data integrity verification with other methods.

DNSSEC
The secured parsing service based on DNS is deployed in the IoT for food safety. The public key distribution based on the DNSSEC is helpful to decrease the complexity of the system deployment and functioning, and can spare the enterprises from applying certifications from the authorized CA.
DNSSEC realizes the trust chain from the root to each domain name. The reliability and undeniability of each record in the DNS can be ensured with the DNSSEC root maintained by CNNIC (China Internet Network Information Center). Distributed by the records in DNSSEC, the public key can be ensured to be non-manipulated. With the digital signature achieved from the trusted third part such as the iotTS, the decrypted data can be ensured to be the original data submitted by the enterprise.
In the state-of-art, there are some works have been done on using the DNSSEC to distribute keys instead of CA. DMAIL uses DNSSEC resolution to do the authentication between MAIL SERVERs [16]. Distributed IKS architecture uses DNSSEC to query service location [17]. DANE protocol provides authentication for TLS transmission [18]. This paper also adopts such architecture to achieve the lightweight public key distribution.

System Architecture
This paper proposes and develops a system for food safety in China. This system is based on GS1 keys, an Electronic Product Code Information Service (EPCIS), and a name service and has been used in a national pilot project for food safety in China. The system is constructed with a hierarchy that includes 3 layers ( Fig. 1). At the enterprise level, master data, event data, and transaction data about the food are collected through mobile phones, tablets, computers, barcode scanners and radio frequency identification (RFID) readers. The information will be managed in the enterprise unit, as the China Food Safety Law states that the food enterprise should assume the main responsibility for food safety. All the information provided by the enterprise will be digitally signed with a private key for each food enterprise. The data provided by the food enterprise are stored in a network database, which can be accessed by an interface called iotIS. There are several subsystems in the Province-level Platform:

Enterprise-level Tracking and Tracing
• Province-level Food Safety Supervision System • Sampling and Inspection System According to the China Food Safety Law, the food supervision organization in each province should be responsible for the food safety issues in the province. As a trustable food traceability service, iotTS is be deployed in the provincial platform to protect food traceability data be trustable. Moreover, iotDS is also be deployed in the provincial platform for the characteristics of its third party public service.
There are several subsystems in the National-level Platform: • National-level Food Safety Supervision System • Sampling and Inspection System In this system, iotIS is a network database for the enterprise-level data, and the service is fully compatible with EPCIS1.1. Additional interfaces are included in the iotIS to meet the requirements of the applications, such as the interface with the China Food and Drug Administration (CFDA) system and the interface for the quality detection system. The name service, iotNS, is provided by the CNNIC. iotDS is deployed to offer the index access of the iotIS Universal Resource Identifier (URI) of each enterprise that the food products go through. The supply chain enterprises deploy their own iotIS and submit an event index automatically to their respective iotDS server. The supply chain enterprises register and maintain their enterprise domain names through the iotNS.
In the proposed architecture of the traceability platform for food safety in China (Fig. 2), the traceability data, environment data, and sampling inspection data are stored in the central database after data filtering and data format normalization. Different service engines will be employed for data processing, including data mining, location-based services (LBS), statistical analysis, decision support, data pushing services, and risk assessment. The platform can support various applications, such as public inquiry, inspection report, risk assessment, early warning, and decision making. In this platform, the trusted data system will be presented as an application component to ensure that the food traceability data in the platform is trustworthy. Compared to the existing solutions, this solution combines the tracking and tracing system with the food inspection system and standardizes the interfaces of data capturing, data communication, data processing and data application, which results in better interoperability, scalability, efficiency and data credibility.

iotTS Information Service
To protect the data in iotIS used for food tracking and tracing system, specific mechanism has to be designed with reference of TPA. In this paper, a methodology of trusted data service, iotTS, is proposed to ensure that the information in the iotIS are non-manipulated and undeniable.
• iotTS is reliable data service provided by a third part. The third part is maintained by government department, supervisor institution or other serving organizations to ensure the fairness, similar with the iotDS which is deployed on the trustable public platform. • iotTS only stores the digital signatures of the master data and event data in the food tracking and tracing system, thus decreasing the amount of data exchange and effectively protect the data owners' privacy. • The data of the food products, the digital signatures and the public keys are separately stored in the enterprise database, the iotTS and the domain names protected by the DNSSEC. The data manipulation happened in any parts will be detected by the client during verification. • The address of the iotTS is maintained and provided by the DNS network. iotTS can be separated. • The public key is distributed using the DNS of the IoT enterprise with the DNSSEC technology.
The iotTS acts as the trusted third part and provides reliable data service for the important information including the master data and event data stored in it. Through the IoT analytical services running on the DNSSEC, the users can get the address and query the public key of the digital signature and the hash function, thus verifying whether the data from iotIS is manipulated or not. Figure 3 shows the relationship between iotTS and the other services in IoT. iotTS provides the following master services: • Service registration and key generation • Master data digital signature submission • Master data digital signature query • Event data digital signature submission • Event data digital signature query http://www.i-joe.org

Paper-A Credible Food Traceability System Based on Domain Name System Security Extensions
Local DNS

CLIENT
IoT Information Architecture  These are the steps for an enterprise to submit data to the trust service.

iotIS(A1)iotIS(A2) iotIS(An) ... iotIS(B1)iotIS(B2) iotIS(Bn) ... iotIS(N1)iotIS(N2) iotIS(Nn
• Get an iotTS service registration • Generate the key pair used in the digital signature and the secret key is used to sign data and the public key is kept in the IoT analytical services protected by DNSSEC. • Sign the master data using the secret key and submit the digital signature and the secret key number to the iotTS. • Sign the event data using the secret key and submit the digital signature and the secret key number to the iotTS.
These are the steps for the client to query and verify.
• Obtain all the information of the food throughout its life time via the DNSSEC and iotIS. • Query the digital signature and key series number of the master data via iotTS • Query the digital signature and key series number of the event data via iotTS • Acquire the public key of each digital signature via the DNSSEC.
• Verify if the master data and the event data have been manipulated by decrypting the signature with the corresponding key.

Service Registration and Key Generation
The enterprise user gets a legal domain name via CNNIC. The domain name is called the enterprise domain name in IoT and represents the enterprise. The iotTS service is activated and configured for this domain name. After that the NAPTR record of the enterprise domain name in IoT will contain the enterprise's URL of its iotTS as shown in Table 1. For instance, the enterprise domain name in IoT of company1 is compa-ny1.cniotroot.cn. And the DNS NAPTR of this domain name will contain the URL of the enterprise's iotTS, for example http://company1.iot-ts.cn:6130/service, in the Regexp column as shown in Table 1.
Before using the iotTS service, the enterprise needs to generate the private RSA key for digital signature, and then adds a sub domain name, for example key_name.key.company1.cniotroot.cn, to be used as the public key domain name. The TXT in the public key domain keeps the public key. The enterprise may generate different RSA keys pairs for different products or batches and stores the public keys in the sub domain name. For example, the enterprise company1 generates a pair of RSA keys for one batch of food products and registers the public key domain name as batch1.key.company1.cniotroot.cn. The public key can be stored in the TXT record of the sub domain name. After then, the querying clients can achieve the public key of batch1 in the TXT record in the domain batch1.key.company1.cniotroot.cn.

Digital Signature and Submission for Master Data
The regMasterData method is used by the enterprise to submit the master data signature to its iotTS for storing. The signature of master data is generated with an RSA private key of the enterprise. The items that submitted to the iotTS include the digital signature, the URI of the master data and the public key domain name.
For instance, 001.item.company1.cniotroot.cn is the URI of a product's master data. The master data, including the product name, materials list, quality guarantee period, number of producing standard, quality level and number of the food producing license, are stored in the URI. The enterprise converts the master data to JSON string, then generates digital signature with the private key named item1.
Then the regMasterData method of iotTS is invoked with three arguments. The argument masterID denotes the URI of the master data domain name, thus urn:cniotroot:id:item:001.item.company1.cniotroot.cn. The argument signature denotes the digital signature. The argument keyID denotes the public key domain name, e.g. item1.key.company1.cniotroot.cn.

Query and Verification for Master Data
When the client queries the digital signature of the master data, he should firstly query the NAPTR record to acquire the URL of the iotTS. Then the client invokes the query Master Signature method passing the URI expression as an argument to acquire the digital signature and the public key domain name of the master data. The client queries the TXT record in the public key domain name and acquires the public key correspond to the digital signature.
When the client verifies the master data, the public key is used to decrypt the digital signature and acquire the hash value of the master data. Then the client conducts JSON conversion on the data acquired directly from iotIS and gets the hash value. If the two hash values are identical, it is proved that the master data has never been manipulated.

Digital Signature and Submission for Event Data
RegEvInfo port is used by the enterprise to summit the event data of products to the iotTS. The event data are stored in the iotTSs allocated for the enterprises of different phases. When the food products are in producing phase, the event data are stored in the iotTS of the manufacture enterprise. When the food products are in transmission phase, the event data are stored in the iotTS of the middlemen.
The enterprise makes a signature for the event data after JSON conversion, and submits the signature to the iotTS through the RegEvInfo port. The event data include the event information required by the EPCIS standard and the food safety related information extended by iotIS. After submission, any manipulation on the event data will trigger the food safety alarm.

Query and Verification for Event Data
QueryEvInfo port is used to query digital signature and public key domain name of specific event.
The client firstly acquires the URL of the food product's iotDS via the NAPTR record in the client's iotNS denoted by the DNS. Then the client acquires URLs of the iotISs of all of the phases, and acquires the URL of the iotTS via the NAPTR record in its iotNS.
After that, the client gets the completed event data throughout the whole lift time of the products including the events' IDs by querying the iotISs of each phase.
The client accesses the iotTSs of each phase, passes the events' IDs as argument and gets all of the digital signatures and public key domain names of the events.
By querying the TXT records of the public key domain names, the client can get all of the public keys.
When verifying the event data, the public keys are used to decrypt the digital signatures and get the hash values of all the events. Then conduct JSON conversion on the event data acquired from the iotISs and get all the hash values. After comparing the two groups of hash values one by one, if every pair of them are identical, the event data are proved not have been manipulated, otherwise there is potential safety issue for the food product.

Performance Evaluation
After introducing iotTS, the procedures of data submitting and querying are changed. In the phase of data submitting, after capturing the user's data, the iotTS needs to conduct JSON conversion and digital signing on the data; then it submits the ID of the data, the digital signature and the key's name through the port of iotTS. In the phase of querying, two extra DNS accesses are need for the user to obtain the address of iotTS and the public key for decrypting the digital signature. The user needs to access the iotTS to obtain the digital signature as well.
With the growing processing capability of the CPU, the influence of JSON conversion and digital signing performed locally on the performance can be neglected. However, the remote access to DNS service and iotTS will influence the procedures of data submission and query.
In this way, the performance testing includes the following three procedures: • DNS performance test is done by measuring the time consumption for the client to obtain the public key from the DNS TXT. • iotTS submit interface performance, to measure the extra time consumption for the iotIS to submit master data or event data. • iotTS query interface performance, to measure the extra time consumption for the client to query the data.
The test server configuration is 4 CPUs, 4G memory, WEB server is based on IIS7, the database is MYSQL5.5. Test client including QUERYPERF and LOADRUNNER 11.

DNS Performance Test
We add a TXT containing the public key to the DNS. Conduct 120,000 times access to the TXT using the BIND QUERYPERF. The test result is listed in Table 2.

iotTS Submit Interface Performance
The concurrent test of the submit interface is to gradually increase the number of concurrent, by recording the response time, and then analyze the concurrency performance. The test results for the iotTS submit interface are shown in Figure 4:

iotTS Query Interface Performance
As well as the methods used in the submit test, we also perform concurrent testing of the query interface. The test results for the iotTS query interface are shown in Fig

Result Analysis
When the number of concurrent data submitted to iotTS is no more than 40 users, the response speed can be obtained within 1 second; when the user is 100, the response speed is less than 1.5 seconds. For the event submission, the delay is acceptable, but for a large number of data submissions waiting time significantly longer, which is to be further improved in the future work.
When the number of concurrent requests is less than 3,000, the response time of iotTS is below 0.006s, and when the user exceeds 3,000, the response performance began decline. If the traceable goods with 5 event including production, inspection, shipping, receiving and retail, when use iotTS in 3,000 concurrent users, the query time increment evaluation is as follows: 0.006 x 5 (with event data) +0.006 (with master data) +0.0064x2 (DNS) =0.0488 seconds, it's almost imperceptible.

Conclusions
In this paper, a credible food traceability system based on DESSEC is proposed. The proposed iotTS technique provides integrity protection for important information in iotIS. With the public key distribution service based on DNSSEC, certification for the middle and small-sized enterprises with affordable cost is provided.
At the same time, a system architecture for food safety validation is also proposed. The proposed system architecture follows the new Chinese Food Safety Law. It has good scalability and credibility, as it supports interactions with the authorized food safety testing organization. The proposed solution combines the tracking and tracing system with the government food inspection system or a third-party food testing system, and defines standard interfaces, which make the system more credible and extendable.
In the future work, digital signature and verification are to be integrated into iotTS, and the complexity of data submitting and querying will be further reduced.