Softscheck.de

Comparison of DNSSEC and DNSCurve securing theObject Name Service (ONS) of the EPC Architecture FrameworkRosenkranz, Demian, University of Applied Sciences Bonn-Rhein-Sieg, 53757 Sankt Augustin, GermanyDreyer, Mark, University of Applied Sciences Bonn-Rhein-Sieg, 53757 Sankt Augustin, GermanySchmitz, Patrick, University of Applied Sciences Bonn-Rhein-Sieg, 53757 Sankt Augustin, GermanySchönborn, Johannes, University of Applied Sciences Bonn-Rhein-Sieg, 53757 Sankt Augustin, GermanySakal, Peter, University of Applied Sciences Bonn-Rhein-Sieg, 53757 Sankt Augustin, GermanyPohl, Hartmut, University of Applied Sciences Bonn-Rhein-Sieg, 53757 Sankt Augustin, Germany Using the Electronic Product Code (EPC) in the future mostly stored on a Radio Frequency Identification (RFID)-chip,it is possible via e.g. the ONS of the EPC Architecture Framework to distinguish each item worldwide and to trace itback in the supply chain to the producer and furthermore to the subcontractors. The paper describes the comparisonof two mechanisms with different security goals to improve the trust level of ONS: DNSSEC and DNSCurve. DNSSECenables integrity and authenticity - DNSCurve additionally enables confidentiality and a higher availability. The necessarymanpower to install DNSCurve is much lower compared to DNSSEC.
The previously mentioned example of the product Viagra Rillustrated on this framework outlines the process involved The project Trusted EPC Administration (TEA)1 has been components of the framework. In this case the starting working on the problems and challenges discussing the point in the figure would be the subscriber (customer, con- trusted global tracking of products along the supply chain sumer). A consumer owns a product with an unique EPC since 2009. Last year the team of TEA published a pa- stored on a RFID-chip. Now the consumer checks the au- per [1] which explained and rated the options to increase thenticity of his product using a terminal in the pharmacy.
the security level in the RFID based supply chain. In this Using a RFID-reader he scans the EPC of his product and paper the focus is the comparison of two possible DNS starts sending a query to the ONS via the terminal. Trusted security extensions. The following scenario has been se- operating environment of the terminal i.e. protecting from cured: A customer purchases a small bottle of an often radio frequency emission is assumed. The ONS receives faked medicine (e.g. Viagra R ) in a pharmacy and wants the EPC and looks for the related EPCIS of the manufac- to verify its originality immediately. He presents the bot- turer. The terminal receives the address of the EPCIS and tle to a RFID-reader inside the pharmacy, which sends the contacts the EPCIS directly with a query containing the acquired data using the internet to the Object Naming Ser- EPC of the product. Now the EPCIS of the manufacturer vice (ONS), Discovery Service (DS) and EPC Information can check whether the requesting user at the terminal is a System (EPCIS). First of all the customer asks for confi- certain consumer, merchant, supplier, partner, anonymous dentiality of the communication (his name etc.), further- etc. and as a result the EPCIS sends the specific informa- more he asks for anonymity against the producer and is tion for the user back to the terminal. Eventually the con- interested to get an answer with integrity. The producer sumer gets the information whether the EPC of his product asks for authenticity because he doesn’t want to answer to is valid or a fake. To allow anonymous requests, not every counterfeiters spoofing correct product numbers (EPC).
consumer must has a certificate, but in this case the con-sumer has only limited EPCIS functionality - according to Every interface marked as a (optional) security service and To allow tracking of products storing an unique EPC, an every communication path between two incident security open and supplier-neutral architecture which provides a services is a possible attack surface and must be provided worldwide and cross-company solution is necessary. The with suitable services which secure the communication and EPC Architecture Framework (Figure 1) provides a plat- raise the resistance against attacks [4]. By ACP the pro- form independent configuration of hardware, software and ducer must be enabled to configure his EPCIS to only send approved information to a subscriber. However, for theONS itself an ACP is not necessary, as the ONS owns noinformation except the address of the producer. This en- 1 Sponsored by the German Federal Ministry of Education and Research No. 01 IS ables the consumer to start an anonymous query to the Figure 1 Security Services in EPC Architecture Framework ONS and prevents the connection between customer and The implementation of the ONS inside the EPC Archi- tecture Framework is based on DNS. On account of thisat least the security goals confidentiality, authenticity and integrity have to be achieved by the ONS. As DNS itselfdoes not suffice the demands of the TEA project (confiden- The Query Front-end of the prototype of TEA is a graphi- tiality, integrity, availability, authenticity/non-repudiation), cal web-based user interface. Authorized subscribers have several technologies to improve the security standard of to validate themselves towards the EPCIS by certificates generated by a Public Key Infrastructure (PKI) [2] in orderto receive specific information about a product provided Table 1 shows the currently most important technologies with an EPC. This allows a software-based solution for the and their representative protective goals.
The Object Name Service (ONS) works like the well-known Domain Name System (DNS). It starts with the resolution of a query, in this case for an EPC, and ends with the an- swer from the resolution in form of an address of an EP- CIS related to the EPC. The essential difference compared to the DNS is that the ONS owns in each case only oneaddress to a possible query based on an EPC and sends it as an answer. Because the functionality and the require- ments of both ONS and DNS are identical, the use of DNS- AT –> Authenticity, CF –> Confidentiality, IN –> Integrity In the following, Domain Name System Security Exten- sions (DNSSEC) and DNSCurve will be discussed.
In the past two years, the Domain Name Service (DNS) was repeatedly attacked mainly by cache poisoning [12] -a denial of service - accomplishing attacks [11].
DNSSEC guarantees the protective goals authenticity andintegrity for ONS information. Additional to the known re- source records (RR) DNSSEC uses specific resource records.
adoption and maintenance. An error-prone migration to DNSSEC applies an asymmetric pair of keys (zone sign- DNSSEC might jam whole zones in result.
ing keys) to each secured zone. Each RR will be signedusing the private zone key. The signature of one or more Until today many home office and small office routers are RR of the same type will be deposited in a signature re- not able to compute DNSSEC queries larger than 512 Byte source record. DNSSEC is capable to use the algorithms (UDP) and simply drop them without notifying the user RSA2/Secure Hash Algorithm 1 (SHA-1), Digital Signa- [9]. This is a limiting factor for the integration of DNSSEC ture Algorithm (DSA)/SHA-1 and RSA/Message-Digest in a network like the EPC Architecture Framework.
Algorithm 5 (MD5). MD5 is not longer recommended be-cause of the insecure MD5 hash algorithm [5].
For this is a known problem a testbed has been establishedin Germany to promote the acceptance of DNSSEC. It is The implementation of DNSSEC required significant changes supported by "Deutsches Network Information Center"in the configuration of the nameserver. Larger compounds (DENIC) - the manager of top-level domain for Germany of the zone file have to be changed or complemented. Among these comes the integration of the key signing keysand thezone signing keys.
DNSCurve is currently the most important competitor ofDNSSEC. DNSCurve allows an easy integration because of its black box architecture and requires only a small amount The product suite DNSCurve [16] is based on the spe- of maintenance costs. Also small office and home office cial elliptic curve Curve25519. DNSCurve can be used to routers can handle the encrypted content of the DNSCurve achieve integrity, authenticity and confidentiality for ONS information. By using DNSCurve the content of trans-mitted and received data packets are neither unrecognized There is only a prototype implementation of DNSCurve modified nor readable for attackers using encryption and available at the moment. A date for a stable version of DNSCurve is not known. The release of a stable version ofDNSCurve is mandatory for its use within the EPC Archi- Only a patched forwarder on the server side and a patched DNS-cache on the client side is needed (Figure 2). Thesecomponents have to be integrated between DNS server and client to handle the incoming and outgoing requests.
Both DNSSEC and DNSCurve ensure the protective goalsauthenticity and integrity. In contrast to DNSCurve, DNS-SEC does not provide confidentiality. In a network likeEPC Architecture Framework that communicates sensitivedata, confidentiality is essential [3]. The consequence is,that ONS secured by DNSSEC can’t serve the confiden-tiality for the customer (subscriber). This gets emphasisedby the example of the customer who wants to buy Viagra R .
The customer has to be anonym against the manufacturer.
Furthermore no third party may get the chance to attainthese information.
Contrary to DNSCurve DNSSEC requires the zone sign- ing keys (ZSK) and key signing keys (KSK) to be updated in a certain interval. In this context the KSK is responsiblefor the proof of identity. The renewal of the KSK is critical Encryption and the key sharing process of DNSCurve is as a breach of security might cripple a whole zone [8].
known as Two Key Communication [13] [14]. Addition-ally - as for asymmetric encryption common - hash keys Another important aspect of DNSSEC is the usage of the will be compared to ensure integrity.
RSA-1024 as encryption of the root zone [10], which - in consideration of major botnets [17] - does not provide suf-ficient trust level. RSA-1024 might be already broken (i.e.
by larger companies or botnets) [15]; but until today thereis no scientific verification. Using DNSSEC the EPC Ar- Two reasons for the slow circulation of DNSSEC are the chitecture Framework might be compromised.
high administrative effort and the involved costs within the 2 stands for Rivest, Shamir and Adleman who first publicly described it DNSCurve uses Curve25519 which is efficient and applies 119 bytes (100%) 341 bytes (287%) 304 bytes (255%) Table 2 Average size of response packets [5] a high security level: A similar level of security is possiblewith 3000-bit RSA, but encryption and authentication with3000-bit RSA is not fast enough to handle modern DNS loads and would require much more space in DNS packets To ensure not only security but also scalability in the EPC The calculation of DSA and ECC keys is significant faster Architecture Framework dealing with enormous amounts as the calculation of RSA keys. DSA and ECC needed a of traffic, a high performance encryption algorithm has to similar length of time to compute the keys, but a RSA and be applied. Using DNSSEC increases the size of the re- DSA key length of 1024 Bit corresponds to an ECC key sponse packets enormously because of the additional Re- length of 160 Bit at comparable trust level. ECC Curve source Records (RR) sent. To illustrate the difference in prime 192v1 has been used to compute the ECC equiva- size, different signed and unsigned DNS requests were sent lent. Therefore the ECC algorithm outperforms RSA and to the server. The names of the requested domains had an DSA by a factor of almost 10 [6]. In view of the perfor- average length of ten characters. The zone signature had a mance the use of DNSCurve in ONS as a component of the length of 1024 Bit. Table 2 illustrates the average size of EPC Architecture Framework is recommended instead of The size of DNSCurve packets is larger in comparison to standard DNS packets. During the sample requests, sizeof DNSCurve packets rose by 255%. Using DNSSEC in- The use of DNS was not to be recommended up to now if creases packet size by 287%. It remains to note that DNS- a high security level had to be guaranteed e.g. in the EPC Curve achieves more protection goals (cf. table 1) then Architecture Framework. Therefore, this paper has been DNSSEC while getting along with smaller packet size. This compared two possible solutions for securing DNS. Table can be traced back to the shorter encryption keys of DNS- 4 summarizes the main findings from the comparison of Curve which results of the use of Elliptic Curve Cryptog- raphy (ECC). Furthermore DNSCurve and standard DNSdo not generate traffic when requesting a non-existing do- main, while DNSSEC does (cf. table 2) [5].
According to Prof. Bernstein - the originator of DNScurve - about 50 billion DNS packets are sent within the .com zone each day. The application of DNSSEC would in- crease the anyway enormous traffic significant. This is counted to the 287% increased packet size compared to DNS and additionally sent response packets when request- ing non-existent domains [5]. Using DNSSEC to secure the ONS of the EPC Architecture Framework which han- dles world wide requests would also increase the traffic sig- The advantage in performance of DNSCurve is shown intable 3. 10.000 pairs of keys have been computed, using DNSSEC does not implement confidentiality. The use of RSA, DSA and ECC. Table 3 shows the mean time mea- RSA 1024 is insecure and common routers might not be sured in seconds needed to compute the belonging keys. To able to process encrypted packets. Using DNSCurve to minimize discordant values, three different CPU architec- ensure the security goals authenticity, integrity and confi- tures Intel Centrino Duo, Athlon X2 and Intel i7 920 were dentiality enables the domain name service in the future to used to calculate the mean time for computing the keys.
be used in environments where a high security level has tobe guaranteed, i.e. ONS.
[14] Bernstein, D.: Cryptography in DNSCurve. 2009 - [1] Sakal, P., Iltisberger, B., Stein, T., Hastrich, M., Pohl, http://DNSCurve.org/crypto.html, 25.08.2009.
H.: Trusted EPC Administration. Bremen 2009.
[15] Bernstein, D.: DNSCurve - DNS forgery. 2009 - http://dnscurve.org/forgery.html, 25.08.2009.
Counterfeit Security using RFID and PKI.
[16] Bernstein, D.: Website DNSCurve Project. 2009 - burg 2007 - http://www.inf.fh-bonn-rhein-sieg.de http://www.dnscurve.org, 25.08.2009.
/data/informatik/fb_informatik/personen/pohl/Auf- [17] F-Secure (Ed.): Calculating the Size of the saetze/Pohl_Wallstabe_High_Level_Counterfeit_ Downadup Outbreak. 2009 - http://www.f-secure .com/weblog/archives/00001584.html, 25.08.2009.
[18] Markoff, J.: Worm Infects Millions of Computers einiger Mechanismen zur Vertraulichkeit, Verfüg- Worldwide. 2009 - http://www.nytimes.com/2009/01/ /informatikmedia/Downloads/Personen/pohl/Auf- [19] Schmeh, K.: Kryptographie - Verfahren, Protokolle, saetze/Pohl_Jung_Roth_Bewertung_des_ Sicherheit- [4] Knospe, H., Pohl, H.: RFID Security. Information Security Technical Report. 2004 - http://www.inf.
fh-bonn-rhein-sieg.de/data/informatik_/fb_informatik/personen/pohl/Aufsaetze/Pohl_Knospe_RFID_Security_050126.pdf.
[5] Wörner, E. (Ed.): Sicherheit von DNS. 2009 - http:// www.informatik.uni-augsburg.de/de/lehrstuehle/swt/se/teaching/ss09/internetsicherheit/Downloads/DNS-Ausarbeitung.pdf.
[6] Gura, N., Patel, A., Wander A., Eberle H., Chang tography and RSA on 8-bit CPUs. 2004.
[7] DENIC (Ed.): DNSSEC - Testbed für Deutschland.
2009 - http://www.denic.de/fileadmin/Domains/DNSSEC/DNSSEC_Testbed_fuer_Deutschland.pdf [8] Heise (Ed.): Router-Inkompabilität. Hannover 2010 - http://www.heise.de/netze/artikel/DNSsec-Router-Inkompatibilitaet-903752.html.
[9] Heise (Ed.): BSI-Studie: Viele Heimrouter beherr- http://www.heise.de/security/meldung/BSI-Studie-Viele-Heimrouter-beherrschen-kein-DNSsec-914777.html.
Dezember DNSSEC-signierte Zone. Hannover 2009- http://www.heise.de/security/meldung/Erster-Root-server-liefert-ab-1-Dezember-DNSSEC-signierte-Zone-814252.html.
stört Online-Weihnachtsgeschäft. Hannover 2009 -http://www.heise.de/security/meldung/USA-Attacke-auf-DNS-Anbieter-stoert-Online-Weihnachts-geschaeft-892686.html.
[12] Heise (Ed.): DNS-Vergifter entführen Tipp- felher-Domains. Hannover 2008 - http://www.heise.de/security/meldung/DNS-Vergifter-entfuehren-Tippfelher-Domains-198527.html.
[13] Bernstein, D.: Curve25519: new Diffie-Hellman

Source: http://www.softscheck.de/publications/20100429_Rosenkranz_Schmitz_DNSSEC_DNSCURVE_RFIDSYSTECH2010.pdf