Smart Ticket Protection: An Architecture for Cyber-Protecting Physical Tickets Using Digitally Signed Random Pattern Markers
©©2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including reprinting/republishing this material for advertising or promotional purposes, creating newcollective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in otherworks.The final, published version of this paper is available under: S. Marksteiner, ”Smart Ticket Protection: AnArchitecture for Cyber-Protecting Physical Tickets Using Digitally Signed Random Pattern Markers,” , Vienna, Austria, 2018, pp. 110-113. doi: 10.1109/CBI.2018.10055. URL:https://ieeexplore.ieee.org/document/8453941/ a r X i v : . [ c s . CR ] S e p mart Ticket Protection: An Architecture forCyber-Protecting Physical Tickets Using DigitallySigned Random Pattern Markers (Workshop Paper) Stefan Marksteiner
DIGITAL - Institute for Informationand Communication TechnologiesJOANNEUM RESEARCH GmbH
Graz, AustriaEmail: [email protected]
Abstract —In order to counter forgeries of tickets for publictransport or mass events, a method to validate them, usingprinted unique random pattern markers was developed. Thesemarkers themselves are unforgeable by their physically randomdistribution. To assure their authenticity, however, they have tobe cryptographically protected and equipped with an environ-ment for successful validation, combining physical and cybersecurity protection. This paper describes an architecture forcryptographically protecting these markers, which are stored inAztec codes on physical tickets, in order to assure that onlyan authorized printer can generate a valid Aztec code of sucha pattern, thus providing forge protection in combination withthe randomness and uniqueness of the pattern. Nevertheless,the choice of the signature algorithm is heavily constrained bythe sizes of the pattern, ticket provider data, metadata and thesignature confronted by the data volume the code hold. Therefore,this paper also defines an example for a signature layout forthe proposed architecture. This allows for a lightweight ticketvalidation system that is both physically and cryptographicallysecured to form a smart solution for mass access verification forboth shorter to longer periods at relatively low cost.
Index Terms —IoT, Security, Cyber-physical systems, Patternmarkers, Cryptography
I. I
NTRODUCTION
Printed tickets are subject to forgery by (partially organized[1], [2]) criminals, as they may achieve high revenues at blackmarket places [3] with a comparably low effort of producingthem. To mitigate this, the research project
Securestamp hasdeveloped a method of applying physically unique, infrared-visible marker pigments on tickets, based on a project partner’spatented work [4]. These pigments could be read and shouldprovide a means to assure the authenticity and integrity of saidtickets in conjunction with a digital checking component inform of this marker pigment pattern transformed in an Azteccode. In order to protect this Aztec code’s authenticity andintegrity, it has to be cryptographically protected. This paper This work was partly supported by the Austrian Research PromotionAgency (FFG) within the Austrian security research program
KIRAS , grantnb. 845491 (project
Securestamp ), of the Federal Ministry for Transport,Innovation and Technology (BMVIT). outlines the composition of this cryptographic protection andprovides an architecture that applies the former in a settingof printers and readers for ticket production and verification,allowing for the composition of physical and cryptographicsecurity to form a lightweight, smart solution for mass accessverification. Based on reading tests with Aztec codes [5], thelatter provide space for 704 bytes for actual coding informa-tion. Due to the size of the pigment pattern, 512 bytes arereserved for its Aztec representation and additional 32 bytesare reserved for provider data. This yields a remaining storagecapability of 160 bytes for encoding protective informationwithin the Aztec code. Therefore, this is the fundamentalworking size for elaborating the cryptographic protection ofthe code. II. R ELATED W ORK
Although, in principle, the proposed architecture could beused with any form of unique physical attribute that can beencoded (into an arbitrary code), the underlying use case isencoding and protecting the infrared-visible marker pigmentsmentioned above into an Aztec code. Therefore, that markingmethod [4] can be seen as foundation of the presented work.Previously known work in this area does, in contrast to thesolution described in this paper, not give comprehensive adviceon cryptographically protecting physical ticket features. Iteither focuses on the hardness of forging the physical charac-teristics combined with challenges for verification [6] or doesnot give any considerations on cryptographically protecting acode from being copied [7]. Furthermore, previous approachesdo not deal with the possibility of stolen ticket printers orverification devices.III. M
ETHODOLOGY
From a system architectural perspective, the process ofissuing and verifying tickets needs protection on three differentlevels: • At a physical level, the authenticity and integrity of themarker pigments and Aztec codes have to be assured;
At device level, secure key management has to take place; • At network level, the key exchange has to be appropri-ately secured.A means for achieving security at physical level is using digitalsignatures (see Section III-B). The key management neededat device level induces the need for a common format storingand exchanging cryptographic keys. This can be achievedthrough the use of digital certificates (e.g. ITU-T X.509 [8]or IETF RFC 5280 [9]) or a format based on the former.Another possibility is exchanging public key lists, preferablybased on an internationally recognized specification, e.g. theformat of the International Union of Railways (UIC) , whichis based on the Extensible Markup Language (XML) [10].Securing the key exchange at network level needs some kindof Public Key Infrastructure (PKI). This can be achieved usinga
Trusted Center (TC) , where communications between printeror reader and the TC have to occur using appropriately secureprotocols in a configuration set that is also deemed secure(for recommendations see [11]). This
Trusted Center consistsof a secure server system under full control of the ticketprovider, securely located in a protected network inside of itsdata center. This system identifies itself to readers and printersusing an own digital certificate for communication (thereforeusing separate communication keys), preinstalled and beingtrusted a priori on the client devices. Subsequently (using asecure protocol as mentioned above), readers can request a listof currently valid code signing keys in an according format(which consists, dependent on the chosen variant, of publickeys of the participating TC(s) and/or currently authorizedprinters) from the TC. Through this operation, invalidatedkeys (e.g. of reportedly stolen or compromised printers) areremoved from the trusted keys list and tickets issued byinvalidated printers (from the time invalidation onward) alsobecome invalid (see Section III-A). All tickets not featuringa successfully verifiable signature are also regarded invalid.Figure 1 shows an example for a possible system architecture.
A. The Problem of Backdating
The possibility of backdating tickets poses an aggravationto the problem of forging tickets. In principle, tickets issuedby stolen printers can be trivially marked as invalid from thereported time of theft onward. For long-term tickets, however,the situation is more complicated. A rouge printer with alegitimate but invalidated key may issue backdated (i.e. beforethe point of invalidation) but still usable tickets (because ofa longer validity period - e.g. annual tickets), which, per se,are indistinguishable from legitimate tickets issued before thetheft. This way, a rouge printer could issue illegitimate butvalid tickets. This can only be prevented if the TC (whichmust not be stolen or compromised) performs the signature orthe security features (i.e. the signed marker pigment pattern)contain a timestamp verifying also the issue time. This yieldstwo variants of ticket signing: • The TC performs each signing operation; https://railpublickey.uic.org • Printers issuing tickets report each operation to the TC.Using the first method, the printer sends the raw informationfor the signature code (including the marker pigment pattern)to the TC via a secure channel (in the sense mentioned above),which subsequently signs the ticket with its own ticket signingkey. In scenario, only TCs are in possession of ticket singingkeys. Other keys, in possession of printers and readers, areonly dedicated to securing communications between those andthe TC(s).The second method requires issuing printers to transmitthe data forming the Aztec code, at least its printer ID, theticket ID, the marker pigment pattern, a timestamp and theissued ticket’s validity period to the TC. If, in this scenario,a printer is stolen (and is therefore able to issue arbitraryillegitimate but valid tickets) its ticket singing key will berendered invalid by the TC as soon as the theft is discovered,generally invalidating all its issued tickets. At the same time,the TC will cease to accept transactions of the printer inquestion (for certificate-based communications this technicallymeans that the TC will discontinue to accept this printer’scommunications certificate). In order to render legit tickets,actually issued before the theft, still valid, ticket-validatingreader devices will be able to request a list of legitimatetransactions from the TC over the secure channel. This canhappen in its entirety or, to save memory, only in parts - e.g.IDs, timestamps and parts or hashes of the respective markerpatterns (leaving a certain residual risk of false positives).For these known transactions, the key of the stolen issuingdevice will be exceptionally accepted, allowing for legitimatetickets to retain their validity. This, however, requires all readerdevices to be capable of storing all of these transactions forthe remainder of their ticket’s validity time. In return, no per-manent online connection for the reader devices is necessary,for the list of transactions can be transferred periodically (e.g.daily). Transactions not reported before the theft, however,are still invalid and will have to be reissued, which is aneglectable issue if the printer devices possess permanentonline connection.
B. Recommended Signature Schemes
Marker pigment patterns and ticket data contain informationthat has, while having no particular need for secrecy, to beunforgeable, meaning their authenticity and integrity has tobe intact. The latter two fundamental requirements to thecryptographic protection of the stored code can be met bydigital signatures [12].Digital signatures, like cryptographic functions in general,leave the choice between symmetric and asymmetric algo-rithms. Former have the disadvantage that they either: • require a distinct key for each relation between signer(TC or printer) and validator (reader), requiring O ( n ) keys or • require changing all signer keys (i.e. re-installing newones on all validator devices) in the event of the theft ofa single validator, as all signer keys have to be known rusted Area cryptographic verification mechanism Trusted CenterTicket Printer Ticket Reader
Issues keys
Ticket and Random Pattern printssigns with digital signature** verifies digital signature trusts publishes trusted signature listand transaction list**optical verification mechanismsigns with digital signature* reports transaction** * Variant a only (Section 2.1)** Variant b only (Section 2.1)
Fig. 1. Example architecture layout to all validators and are therefore exposed in the aboveevent.Asymmetric schemes do not have these disadvantages, becausethe respective public key is actually intended to be known.This means that the theft of a validator does not compromiseany signer key. Therefore, the marker pigment patterns andthe necessary additional information can be coded directlyinto the 2D code and be protected by a digital signature,as this information does not need secrecy but very wellneeds authenticity and integrity. For this reason, asymmetricmethods are preferable for this use case. The specificationsin [13] provide standardized schemes, of which the first, theDigital Signature Standard (DSS) provides three possibilitiesof generating digital signatures: • The Rivest-Shamir-Adleman (RSA) algorithm ; • The Digital Signature Algorithm (DSA) ; • The Elliptic Curve Digital Signature Algorithm (ECDSA) .ISO 14888-3 [14] defines twelve standards, partly overlappingwith the DSS or variants of DSA or ECDSA. Not variants ofthese are: • Variants of the (EC)Schnorr (as (EC-)(F)SDSA) algo-rithm; • The Pointcheval and Vaudeney (PV) scheme.Of the above, the RSA algorithm is ruled out, as secure keylengths for future applications using this algorithm have to bemore than 4096 bits [15] and the ciphered code length is equalor longer than the key length (in fact, with a maximum of 132bytes of space, anything above RSA-1024 does not fit into thesignature space). The private key-enciphered hash value of thedigital signature would therefore yield a minimum length of512 bytes, which exceeds the provided space. The DSA onthe other hand, is recommended for legacy applications onlyby the
European Union Agency for Network and InformationSecurity (ENISA) and is, therefore, also not suitable [15]. Apartfrom the exclusion of RSA and DSA algorithms, the relatively short key length suggests
Elliptic Curve Cryptography (ECC) algorithms for the present use case. Digital signature genera-tion and verification with ECDSA using key lengths > = SecureHash Algorithm 2 (SHA-2) with an output length > =
224 bits[15]. The ECC algorithm combinations fulfilling this criterionalso fulfil the length requirements mentioned above. Despite ofthis, the ENISA recommends only the algorithms (EC)Schnorrand (EC)KDSA (Korean DSA) for future applications of theECDSA. The reason is the weak formal security proof ofother ECDSA algorithms. (EC)KDSA, however, cannot beused, for it lacks of a reference implementation. Schnorr’salgorithm [17] was patented, but this patent has expired andalso an optimized version of the algorithm (EC-SDSA-opt) hasbecome part of an ISO standard [14]. Therefore, it is preferablefor its security proof and also for it can achieve shortersignature sizes than the DSA [15]. Furthermore, due to itssimplicity, it allows for optimizations and it also implementsrandomized hashing [18]. Although this algorithm was notwell proliferated so far, it got worldwide attention by
Bitcoin ’sannouncement to replacing the ECDSA with Schnorr as itsdigital signature algorithm in 2017 [19]. Apart from theabove, all cryptographic functions require a cryptographicallysecure random number generator (for ECDSA, for example,according to the recommendations from the German
Bunde-samt f¨ur Sicherheit in der Informationstechnik (BSI) [20] orthe
American National Standards Institute’s (ANSI) standard
X9.62 [21]).
C. Resulting Signature
The resulting Aztec code should, apart from the markerpigment pattern and the digital signature, contain at leastn identification number (ID) for each the issuing printer,the TC, the ticket provider and the ticket itself, as well asthe ticket’s validity time (period or date-of-expiry) and anissue timestamp (Figure 2 shows an exemplary code layout).Information already contained in the provider data (32B) maybe omitted. For better interoperability, the code may holdinformation about cryptographic parameters (e.g. used ellipticcurve, hash algorithm, etc.). The digital signature must protectall code components (except the signature itself).
Fig. 2. Example code layout.
IV. C
ONCLUSION AND O UTLOOK
This work demonstrated that
Elliptic Curve Cryptography(ECC) provides a means to securely embed a physically uniquemarker pigment pattern into Aztec codes. It further outlinedan architecture that allows for successful (part-offline) issu-ing and cryptographic verification of tickets and, especially,to overcome the problem of distinguishing legitimate fromillegitimate long-term tickets, validly issued by legit, but stolenor corrupted printers using transaction tracking or digitalsigning in a
Trusted Center (TC) . Future work will includeimplementing and testing the presented solution and furtherdeveloping the latter to forge a market-ready product.A
CKNOWLEDGMENT
The author wants to thank his fellow colleague MartinWinter for his support in this work.R
EFERENCES[1] J. Ayling and R. Broadhurst, “The suppression of organized crime:New approaches and problems,” in
Policing and Security in Practice .Springer, 2012, pp. 37–55.[2] S. Schneider,
Canadian Organized Crime . Toronto, Ontario: CanadianScholars, 2017.[3] L. Tuffanelli, “Super bowl the latest front in ticketing war,”
Ent. &Sports Law. , vol. 31, p. 10, 2014.[4] E. Ulrich, “Einrichtung zum verarbeiten einer darstellung eines sicher-heitsdruckes auf einem informationstr¨ager,” Jan. 15 2014, europeanPatent No. EP2001688, Filed Apr. 3rd, 2007, Issued Jan. 15th, 2014.[5] International Organization for Standardization, “Information technology- Automatic identification and data capture techniques - Aztec Codebar code symbology specification,” International Standard, InternationalOrganization for Standardization, ISO/IEC ”24778”, 2008.[6] W. Clarkson, T. Weyrich, A. Finkelstein, N. Heninger, J. A. Halder-man, and E. W. Felten, “Fingerprinting blank paper using commodityscanners,” in , May2009, pp. 301–314.[7] L. Finˇzgar and M. Trebar, “Use of nfc and qr code identification inan electronic ticket system for public transport,” in
SoftCOM 2011,19th International Conference on Software, Telecommunications andComputer Networks , Sept 2011, pp. 1–6.[8] ITU Telecommunication Standardization Sector, “Information technol-ogy - Open Systems Interconnection - The Directory: Public-key and at-tribute certificate frameworks,” International Telecommunication Union,Technical Specification X.509, 2012. [9] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk,“Internet X. 509 Public Key Infrastructure Certificate and CRL Profile,”Internet Requests for Comments, Internet Engineering Task Force, RFC5280, 2008.[10] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau,“Extensible markup language (xml) 1.0 (fifth edition),” World Wide WebConsortium, W3C Recommendation 26 November 2008 26 November2008, 2008.[11] S. Marksteiner and H. Vallant, “Towards a secure smart grid storagecommunications gateway,” in
Proceedings of the 2017 Smart CitySymposium Prague (SCSP) . New York, NY, USA: IEEE, May 2017,pp. 1–6.[12] E. Barker, “Recommendation for Key Management Part 1: General(Revision 4),” NIST Special Publication, National Institute of Standardsand Technology, SP 800-57, 2016, retrieved at February 16, 2018.[Online]. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf[13] National Institute of Standards and Technology, “Digital SignatureStandard (DSS),” Federal Information Processing Standards, NationalInstitute of Standards and Technology, FIPS Publication ”186-4”, 2013.[14] International Organization for Standardization, “Information technology- Security techniques - Digital signatures with appendix,” Interna-tional Standard, International Organization for Standardization, ISO/IEC”14888:2016”, 2016.[15] N. P. Smart, V. Rijmen, B. Gierlichs, K. Paterson, M. Stam, B. Warin-schi, and G. Watson, “Algorithms, key sizes and parameters report -2014,” European Union Agency for Network and Information Security,Tech. Rep. TP-05-14-084-EN-N, 2014.[16] E. Barker and A. Roginsky, “Transitions: Recommendation forTransitioning the Use of Cryptographic Algorithms and Key Lengths(Revision 1),” NIST Special Publication, National Institute of Standardsand Technology, SP 800-131A, 2015, retrieved at February 21, 2017.[Online]. Available: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf[17] C. P. Schnorr, “Efficient identification and signatures for smart cards,”in