JSON Sensor Signatures (JSS):End-to-End Integrity Protection from Constrained Device to IoT Application

Henrich C. PohlsChair of IT-Security, University of Passau, Germany

Email: hp@sec.uni-passau.de

Abstract—Integrity of sensor readings or actuator commandsis of paramount importance for a secure operation in theInternet-of-Things (IoT). Data from sensors might be stored,forwarded and processed by many different intermediatesystems. In this paper we apply digital signatures to achieveend-to-end message level integrity for data in JSON. By signingJSON on the constrained device we extend the end-to-endintegrity protection starting from the constrained device toany entity in the IoT data-processing chain. Just the JSONmessage’s contents including the enveloped signature and thedata must be preserved. We reached our design goal to keepthe original data accessible by legacy parsers. Hence, signingdoes not break parsing. We implemented an elliptic curvebased signature algorithm on a class 1 (following RFC 7228)constrained device (Zolertia Z1: 16-bit; MSP 430). Further-more, we describe the challenges of end-to-end integrity whencrossing from IoT to the Web and applications.

Keywords-integrity, digital signatures, ECDSA, IoT, JSON

I. INTRODUCTION

Integrity is the “property that data has not been alteredor destroyed in an unauthorised manner” [1]. It can beachieved on the transport-layer and on the message level.Transport-layer integrity protects the channel between twocommunicating entities, such that inside the channel in-tegrity cannot be violated with out being detected by thecommunication partner. Message-level integrity creates anintegrity check value, e.g., using digital signature, overthe message and then send message and signature over anunsecured communication channel.

In the Internet-of-Things, sensory information is gatheredby constrained devices (see [2] for classification) and thedata is then forwarded to other things or to servers. It mightbe immediately processed, but often it is stored in messagequeues to be picked up later by applications to achieve thedesired functionality. For example assume the sensor withthe thermistor to continuously push his readings into a mes-sage queue on a cloud server. Asynchronously this messagequeue is read by several different applications. Protecting theintegrity for those type of loosely connected processing canbe achieved by message-level protection mechanisms. Usinga cryptographically secure signature schemes allows verify-ing that data has not been modified in unauthorised ways.Additionally, you gain origin-authentication, i.e., verifyingwhich entity signed the data.

A. ProblemsIn today’s Internet-of-Things (IoT) the cryptographic pro-

tection for integrity is hardly to be found at all [3] or isprotected for the transport layer [4]. As said, transport layerprotection does not protect the data after the transmission.Transport layer protection is still an important step, but itsintegrity protection cannot be seamlessly extended towardsfuture processing by entities ‘down-stream’.

Digital signatures, as a cryptographic tool, are messagestructure and message semantic independent. They protecta string of bits, in exact that order from the first to the lastbit. Whenever this string of bits cannot be recovered, thesignature and with it the integrity of the data, can no longerbe verified. To achieve message level protection in the IoTrequires that the message’s data structure, which was used togenerate the string of bits that was signed, to be: (1) eitherstill intact as signed, or (2) reproducible from received data.

However, currently a cryptographically verifiable proofof integrity and origin is hardly ever seamlessly preservedfrom the sensor-based IoT-world to the world of flexibleinterchangeable services and their applications.

B. ContributionsThis paper’s goal is to protect integrity of information

in an end-to-end fashion in the IoT data processing chain:starting the earliest, generally already on the device [5], andextend it seamlessly all the way up to the applications. Thecontributions of this paper are as follows:

• We generate a cryptographically strong asymmetricsignature based on ECDSA with NIST p160 curve,directly on a class 1 constrained platform [2] (ZolertiaZ1: MSP 430@16 MHz; 16-bit; 8KB RAM; 92KBROM [6]).

• Our format encapsulates an ECDSA signature into thesame data structure it protects.

• Our format does not require any additional steps toaccess the data that it protects, so parsers which donot understand the signature, find the information atthe same place as within an unsigned data structure.

We choose the data structure to be Javascript Object Notation(JSON) due to the widespread usage of JSON [7]. Thegeneral idea and the design goals are applicable to any datastructure.

With a data structure understood by many entities in theIoT data processing chain, there is little need to re-formatthe data. Hence, the signature value can still be verifiedby more subsequent entities. To achieve this, our proposedsyntax seamlessly carries the integrity protection signaturemeta-data as additional JSON elements in an otherwiseunchanged JSON. We will refer to our format as JSONSensor Signatures, or JSS in short. JSS achieves end-to-endmessage-level integrity protection and can be used with anydigital signature mechanism.

II. BACKGROUND AND RELATED WORK

A. Cryptographic Primitives for Digital Signatures on Con-strained Devices

There are several different approaches to allow cryptoon constrained devices: On the one hand lightweight-cryptosuitable for severely resource constrained devices and onthe other hand solutions based on traditional cryptographicprimitives.

We acknowledge the need for lightweight cryptographyand special schemes. Solutions like the ultra-lightweightHummingbird [8] allow to bring crypto to nearly any devicein the IoT (8-bit microcontroller ATmega128L). These andthe ongoing developments are important to work towardsa secure IoT, which is currently not achieved by solutionson the market [3] drastically showed. Especially those basedon asymmetric keys, which offer strong origin authenticationand scaleable key distribution [9], are costly.

That changed when elliptic curve based cryptography(ECC) gained adoption. ECC was presented already in1986 independently by Miller [10] and Koblitz [11]. Inrecent years, ECC has become standard in the IoT devicecontext. NIST has standardised the Elliptic Curve DigitalSignature Algorithm (ECDSA) in 2000 [12]. Implementationfor wireless sensor networks exist, e.g., TinyECC [13], Na-noECC [14], or NIST’s ECClight [15]; and they have beenfurther optimised [9]. Another example of ECC being theperfect candidate for constrained devices, besides Ayuso etal.’s work [9]: the 160bit curve implementation by Kern andFeldhofer [16] or the very lightweight ECC based construc-tion for authentication of Braun, Hess and Mayer [17] onRFID-type devices. Recently, NIST’s curves have been criti-cised [18] and the proposal by Bernstein named Curve25519with the signature algorithm named ed25519 is currently enroute to standardisation [19]. additionally, it is claimed tobe less problematic for implementers.

In general, ECC has shown to be usable in softwareimplementations, and is well supported in today’s recent IoThardware platforms [20], [21], [22]1. From this we assumethat ECC signature generation and verification becomesincreasingly pervasive for IoT’s hardware.

1We hope it stays hardware supported, as in TI’s CC2538, and non NISTcurves are added. However, it has recently been dropped again (see: http://blog.spd.gr/2015/04/to-cc-or-not-to-cc.html).

B. Message-Level Integrity

Cryptographically digital signatures protect a string ofbits. When facilitated for message-level integrity protectionit becomes important to devise the procedure on how themessage’s content is supplied to the cryptographic algorithm.At this point the mechanisms must be tailored to fit thestructure of the data they protect.

In the world outside IoT, XML is a common datastructure. The XML Digital Signature Specification (XML-DSig) [23] was standardised with a couple of canoni-calization methods, allowing to build a single canonicalserialisation of XML data into XML [24]. XML Signatureshave rightly been criticised for their complexity [25] andtherefore are not a good choice for the constrained IoTworld. Gutmann gives helpful advice [25] and proposesdesigning a signature format such that it can be linearlyparsed. The proposed order of elements shall be: “signaturehash algorithm indicator; data; signature;” [25]. It wouldalso be possible to use existing signature formats for email,like S/MIME or PGP, already suggested in [25]. Ernstdesigned “Really simple Signatures” (XML-RSig), wherethe signature is added as a child node to the node that itsigned [26]. The over-flexibility of XML transformationsand XML-DSig results in security problems [27], [28].

Another general problem of digital signature schemes isthat the integrity of the information’s representation as abit string is protected. Hence, XML-DSig would require forverification that all characters of the message are alwaysin the exact same order as during signature creation. Tosimplify XML-DSig Ernst assumed that the order of char-acters has not changed. In XML this is usually done byremoving unnecessary space, line breaks, etc. and then orderthe children alphabetically. Please keep this need in mind, aswe will come back to this issue of canonicalization (C14N)XML is deemed to be too complex for the constrainedworld of the IoT. To bridge the gap we wanted to baseon a data structure that is widely used in the IoT world.In the following we will go into detail on three slightlydifferent proposals: IETF’s JSON Web Signatures (JWS),IETF’s Constrained Object Signing and Encryption (COSE),and JSON Clear Text Signatures (JCT).

C. JSON Web Signatures (JWS)

Javascript Object Notation (JSON) has become very pop-ular to represent data in the IoT domain2. It is standard-ised [29], simple, offers structure, and can be self-explainingto humans if semantical names are used. Table. I has a JSONformatted temperature value of 23.4 with some meta-data.One candidate to sign JSON is the so-called JSON WebSignature (JWS) [30] that is currently discussed in IETF’sJOSE working group as an draft. There is also a list of

2http://postscapes.com/internet-of-things-protocols

Table IJSON EXAMPLE

{ "measurement_id": 3,"node_id": 1337,"temp": 23.4 }

Table IIJWS SHORTENED EXAMPLE ADAPTED FROM [30]

{ "payload":"eyJpc3MiO· · ·nVlfQ","protected":"eyJhbGciOiJFUzI1NiJ9","header":{"kid":"e9bc0· · ·2db0d"},"signature":"DtEhU3lj· · ·23NU1Q" }

above ‘· · ·’ indicates removed bas64url-encoded characters;linefeeds and spaces added just to ease visual consumption;

algorithm descriptors [31], which includes some for ECC-based signature schemes (e.g., NIST ECDSA using P-256and SHA-256 is named ‘ES256’). An example of JWS,following the current draft’s example, is shown in Table II.

If one follows the IETF draft for JWS, the payload willalways be base64url-encoded3. Because the IETF draft forJWS states that “the payload member MUST be present andcontain the value BASE64URL(JWS Payload).” [30] Thethree base64url-encoded result strings and the JWS Unpro-tected Header value are represented as members within aJSON object [30].

Already Spourny noted that JWS requires transporting alot of data as base64url-encoded [32]. In JWS the base64url-encoded values are the input for the integrity protection. Thisencoded payload becomes the normalised representation. Aslong as this does not change this representation can be signedand verified. However, this has one obvious drawback:base64url-encoded JSON is no longer human readable. An-other, quite heaving weighting downside: legacy code in theapplication domain can no longer parse the actual payloaddata of signed message. Legacy code that understood Table. Icannot find the ‘temp’ in Table. II without understanding andreversing the signature’s added encoding.

While additional encodings might be tolerable for encryp-tion of data, where encrypted data can only be read bycode that understands decryption, integrity does not requireto restrict easy access to protected data. In our opinion,adding a signature for integrity protection shall not makethe protected data any harder to parse.

D. CBOR Object Signing and Encryption (COSE)

Very recently, the use of ideas from JOSE on other en-codings than JSON is discussed. Instead of using base64url-encoding of JSON, COSE proposes to use the ConciseBinary Object Representation (CBOR). CBOR is a dataformat aimed for small code size and small message size

3Base64 Encoding with URL and Filename Safe Alphabet (RFC4648)

Table IIIJCS EXAMPLE ADAPTED FROM [36]

{ "measurement_id": 3,"node_id": 1337,"temp": 23.4,"signature":{ "algorithm": "ES256",

"publicKey": { "type": "EC","curve": "P-256","x": "lN· · ·02Ck","y": "Lm· · ·8iFA" },

"value": "C1qP8· · ·CuUHg" } }

above ‘· · ·’ indicates removed characters;linefeeds and spaces added just to ease visual consumption;

described in RFC 7049 [33]. This IETF group, likely tobecome a working group, is called COSE [34]. COSEhighlights that “each use of JSON is replaced by theequivalent use of CBOR” [34] and that especially “wherethe output of the base64url function was to be used as aninput to a cryptographic algorithm, instead the input is useddirectly” [34]. COSE proposed the syntax for its encryptionin a draft called CBOR Encoded Message Syntax [35].

To recap, instead of using base64url-encoded JSON,COSE uses CBOR as a serialisation. However, COSErequires the CBOR representation not to be changed byintermediaries: “The payload is wrapped in a bstr4 to ensurethat it is transported without changes, if the payload is trans-ported separately it is the responsibility of the application toensure that it will be transported without changes.” [35] ACBOR encoder and a decoder shall be easily implementedon a class 1 [2] constrained nodes [35].

COSE requires not only CBOR decoders in upper layers,it still requires that CBOR-encoded payload is not changedafter signed, even though CBOR allows intermediaries to re-arrange data encoded inside CBOR structures. Hence, [33]explains the creation of canonical CBOR. Canonical meansthat two encoder implementations starting with the same in-put data will produce the same CBOR output. Following this,COSE’s encoded message syntax requires that “CanonicalCBOR (Section 3.9 of RFC 7049) MUST be used” [35].

E. JSON Clear Text Signature (JCS)

In the end of 2013 Rundgren proposed JSON ClearText Signature (JCS), where the signature is encoded muchlike an enveloped XML signature, just all in JSON. Herecently states that “[u]nlike IETF’s JWS [JOSE], JCS wasdesigned to be an integral part of a JSON object rather thanembedding the signed data.” [36]

JCS does not list the accessibility of the content as theirmain design goal. Important to note is that JCS has a “poten-tial dependency on canonicalization” [36]. Further note that

4bstr is a byte string; a fixed-length array of bytes

23.4°Cverified

IoT-Middleware(s), IoT-Node(s), ...

servers & applications can verify integrity

1.) read temp=23.5°

JSON: {temp:23.4, "signature":"MEYCwoBK"}

2.) sign with ECDSA

JSON: {temp:23.4, "signature":"MEYCwoBK"}

3.) sendsigned temp.

constrained IoT-devices protect integrity

Figure 1. Our goal: seamless integrity protection starting early;our solution: signing JSON-formatted data on the constrained device

in JCS “this part has been extremely simplified” [36] as “JCSonly relies on predictable serialization of JSON data.” [36].

III. DESIGN GOALS OF JSS

Signatures provide an added value. However, we stronglyfeel that adding them must not break existing workflows.

1) keep data in signed messages still accessible to theIoT value chain in the same manner as if it would nothave been signed

2) keep JSON’s simplicity, as it might be the reason whyJSON has seen widespread adoption especially higherup in the IoT data chain

3) limit the increase in message size due to meta-data4) signature is generated and verified on constrained

deviceThe latter allows starting end-to-end protection at the earliestpossible moment. Note, when we talk about generation ofsignatures, we implicitly include the ability to verify as well,e.g., signed commands are verified on the constrained deviceitself.

IV. JSS FORMAT: SIGNATURE ENCAPSULATION IN JSON

We have chosen to select JSON because the data structureis widely used in the higher layers. Future work is toimplement and compare integrity protection for other datastructures, e.g., CBOR, on constrained devices.

There are again several ways to embedded signatures.Let us highlight two following the XML-DSig nomencla-ture [23] for their naming:

enveloped: signature-related JSON elements added aschildren inside JSON object that was signed (seeTab. V)

Table IVENVELOPED JSS SYNTAX

{ "protected":{<plain headers>},<plain payload>,"signature":"<base64url-encoded signature>" }

linefeeds and spaces added just to ease visual consumption;

Table VENVELOPING JSS SYNTAX

{ "protected":"<plain header>","payload":{<plain payload>},"signature":"<base64url-encoded signature>" }

linefeeds and spaces added just to ease visual consumption;

enveloping: payload is a JSON element added as achild in a signature JSON object (see Tab. IV)

XML-DSig also knows detached signatures, however a de-tached signature would (a) not keep the signature simplyalongside the JSON payload and (b) it would require to ahave a message id that could be used to link the signatureobject to the JSON payload object that was signed. Hence,detached signatures are not considered further.

To attain the first design goal, we cannot change the levelat which the payload’s values reside. So, only an envelopedsignature can be used.

The outcome of an enveloped JSS for the JSON payloadfrom the example would look as shown Table VI.

A. Steps to canonical JSON

The design goal is to keep the JSON payload, i.e.,the initial JSON formatted data, unencoded. However,JSON can contain spaces ( ) and line breaks and moreimportantly, JSON elements can be re-ordered, e.g.,{ "b":"two", "a": 2 } carries the same informa-tion as {"a": 2, "b": "two"}. Cryptographic signaturemechanisms will protect a string of bits, and the above twoJSON strings will get a different binary representation. Thus,a signature on the first would not verify on input of thesecond. We need to transform the payload into a canonicalrepresentation. Such a canonical transformation returns thesame string representation repeatedly if the information inthe JSON object is the same. This is required, as this is theninput to the digital signature’s hash function.The canonicalJSON shall remain valid JSON and parseable with anystandard compliant JSON parser. Spending a small fractionof compute power on this additional step of canonicalizationallows to keep JSON’s flexibility, e.g., allows elements to bearranged differently without changing meaning.

However, currently there is no agreed standard for thistransformation. We found one proposal from OLPC [37],one long expired IETF draft from 2012 [38], and Rundgrencalled the steps “normalization” in JCS [36]. In JCS this is

not a canonical form because still “[t]he original propertyserialization order must be preserved” [36] during parsing.

Canonicalisation shall not be confused with minification,as these processes usually only removes all unnecessarywhitespaces and comments. Serialization transforms a rep-resentation of a data structure into a series of bits. Canoni-calization refers to a particular serialization with the aboveproperty: {"a":2,"b":"two"} 6.

We adopted OLPC’s procedures to generate “canonicalJSON” [37], but removed the final encoding step.

• No whitespace• No escape sequences in strings other than \and \\; all

other represented literally, including control characters• No trailing commas• Object keys sorted by Unicode character values (code

points); sorting occurs before adding escape sequences• Non-integers and initial zero-padding not allowed

B. Steps to generate the JSON-Sensor-Signature (JSS)

The following steps are close to the IETF draft for JWS.For the generation of the signature value, also JSS needsto have the payload being base64url-encoded. However, weuse the canonical form and forgo with JWS’s requirementthat “[t]he payload member must be present and contain thevalue BASE64URL(JWS Payload)” [30].

1) Initialisation phase (done only once): Key Setup foran ECC key, e.g., curve secp160r1.

2) Creation of the JSS header that specifies the algorithmidentifier: following [31] the reference is ES160.

3) Encoding jss.protected header’s contents usingbase64url-encoding: eyJhbGciO1NiJ9Cg 5

4) Canonicalize JSON payload; "measurement_id":3,"node_id":1337,"d ata":23.4 6

5) base64url-encode the payload: eyAibWVhzLjR9Cg 5

6) Concatenation of header’s contents and payload:base64url-encoded header followed by character’.’ followed by base64url-encoded payload:eyJhbGciO1NiJ9Cg.eyAibWVhzLjR9Cg 5

7) Hash the concatenated string using the cryptographichash function defined in header: SHA-256

8) Sign hash using secret signing key with the selectedsignature algorithm: NIST ECDSA secp160r1

9) base64url-encode the generated cryptographic signa-ture: MEYCwoBK· · ·27rM9KLVF8pA 5

10) Integrate header (in plain text) in front and signature(base64-url-encoded) at the end of the payload, seeTable IV

C. Steps to verify the JSON-Sensor-Signature (JSS)

Assuming we have received the data already in canonicalform alleviates the need to do a canonicalisation on the

5shortened example, not the real value

Table VIJSS EXAMPLE SIGNED ENVELOPED SIGNATURE

{"jss.protected":{"alg":"ES160"},"data":23.4,"measurement_id":3,"node_id":1337,"jss.signature":"MEYCwoBK· · ·27rM9KLVF8pA"}

above ‘· · ·’ indicates removed bas64url-encoded characters;linefeeds added just to ease visual consumption;

constrained device (so we can skip step 4 in the followinglist), the signature will fail if it is not in that form.

1) Extract JSS’s header: {"alg":"ES160"}.2) Parse algorithm identifier and initialise the correspond-

ing algorithm: ES160 refers to ECDSA based onNIST’s curve secp160r1.

3) Encode header using URL-safe base64-encoding:eyJhbGciOiI1NiJ9Cg 5

4) Extract remaining JSON integrity protected payload:"measurement_id":3,"node_id":1337,"data":23.4 6

5) Canonicalize and and encode payload using URL-safebase64-encoding: eyAibWVhzLjR9Cg 5

6) Extract signature value:MEYCwoBK· · ·M9KLVF8pA 5

7) Load the trusted public verification key for the sender8) Concatenation of the header’s contents and the pay-

load, so the base64url-encoded header followed by thecharacter ’.’ followed by base64url-encoded payload:eyJhbGciOiI1NiJ9Cg.eyAibWVhzLjR9Cg 5

9) Hash the concatenated string using the cryptographichash function defined in the header: SHA-256

10) Verify hash using the signature algorithm selected,here ECDSA NIST’s curve secp160r1, using thesender’s public verification key

Finally, the example from Table I would look as Table VIwhen the JSS is enveloped, e.g., the signature’s header isbefore the payload in canonical form and the signature valueis tailing, following Gutmann’s advice [25], Additionally, allunnecessary white spaces and line breaks are removed.

V. JSS IMPLEMENTATION AND PERFORMANCE ONZOLERTIA’S Z1

The implementation was performed as a proof of concept.Following the classification of RFC7228 [2] Zolertia’s Z1,based on MSP430 with 8KB RAM and a 92KB Flashmemory [6], is a class 1 (C1) device.

A. JSON and Canonicalization

JSS keeps the JSON object’s payload unchanged as longas the data processing can handle JSON. Note, the resultingJSS is still valid JSON and the original JSON data isstill present and parseable as before. However, to keepthe JSON payload accessible and allow intermediaries to

6linebreaks just appear in this printed version

Table VIIPERFORMANCE OF JSS ON ZOLERTIA Z1; AVERAGE OVER 200 RUNS

JSS complete generation∗ 2123,89 msjust the signature calculation 1016.09 ms

Codesize Client/Sender∗∗ 63,927 bytesCodesize Server/Receiver∗∗ 59,451 bytes

∗ includes temperature sensing, creating JSON string,ECC initialisation, base64url encoding and signing

∗∗ includes code for UDP network communication

re-arrangement the elements, we needed to bite into thebitter apple of canonicalization (c14n), which adds com-plexity. Only due to canonicalization of the JSON objectthe verifier can re-create the exact same bit representationthat was signed. Thus, the verification can succeed even ifre-arrangements where done that did not affect the actualinformation, e.g., if {"a":2,"value":"content"}becomes { "value": 2"content", "a":2 }. Perfor-mance hits by canonicalization can be avoided. The actualstep of canonicalisation must not be performed on theconstrained devices itself. For signature generation the JSONmessage can already be assembled in its canonical form, e.g.,the canonical form is hardcoded. The verifier might eithera powerful entity outside the constrained world or can begenerated by more powerful intermediaries before forwardedinto the constrained world.

B. Performance using NIST p160 on Zolertia Z1

Table VII states the speed of our prototype as a referencefor others to compare. The prototype was build using theECClight library [15] for Contiki [39] as a starting point.It was developed by employees of the National Institute ofStandards and Technology (NIST), and others [15]. Fromthis public domain library, the core ECDSA implementationwas isolated and remaining code removed. For the NIST’sp160 curve (secp160r1), the private key and a public cer-tificate was generated on one Zolertia Z1 [6] and exported.The private key was stored in code on the Z1 that signs andthe public certificate was hard-coded into another Z1 thatverifies. Finally, the JSS as a JSON object was sent via UDPfrom the signing Z1 to the verifying one. We implementedthe JSON canonicalization method including a BASE64URLencoding. Code is planned to be released as open source.

VI. CONCLUSIONS

We have implemented a cryptographically strong digi-tal signature based on ECC in software on a constraineddevice. For the software prototype we used ECDSA p160NIST, which is arguably not secure [18], but suffices asa performance indicator. Future work is to build it oned25519 [19]. The first challenge to overcome was thedifference in processor bit-width of the constrained deviceand the normal world of web based services, e.g., 16 bit to32/64 bit. The lesson learned was to not underestimate the

effects that these differences have on the encoding of thecryptographic key material and of the message itself.

Second, we faced the challenge of being able to re-construct the exact same bit representation that was signed.Due to widespread use on higher IoT processing we wantedto keep JSON as flexible as possible and chose the road ofcanonicalization, e.g., like COSE did with canonical CBOR.We opted agains encoding a flexible and human-readableformat into a non-human readable encoding, like base64url-encoded JSON, as done in JWS.

In this paper, we have described the steps to canonicalisethe data, and to transport a signature value and necessarymeta-information inside the JSON data that it protects. UsingJSON from the constrained node, removes the need to re-format the data and thus the integrity verifying signaturecan be preserved and checked. Using a canonical represen-tation allows intermediaries to re-arrange the JSON withoutinvalidating its integrity.

In the prototype, the elliptic curve cryptography, theencoding and parsing of the JSON data takes only about twoseconds. Thus, our prototype demonstrates that even a class1 constrained device, as defined in [2], like the Z1 (MSP430@16MHz) [6] can seamlessly lay the foundation for end-to-end integrity protected sensor-to-world communication.

Future work is to implement and compare potential gainsof using other representations, e.g., canonical CBOR.

ACKNOWLEDGEMENTS

The research leading to these results has received fundingfrom the European Union’s Seventh Framework Programme(FP7/2007-2013) under grant agreement no 609094. Theauthor would like to thank especially Johannes Bauer andBenedikt Petschkuhn for their help with the implementation.

REFERENCES

[1] ISO/IEC, “ISO-IEC 7498-2: Information processing systemsOpen Systems Interconnection Basic Reference Model. Part2: Security Architecture,” ISO Geneve, Switzerland, 1989.

[2] C. Bormann, M. Ersue, and A. Keranen, “Terminologyfor Constrained-Node Networks,” RFC 7228 (Informational),Internet Engineering Task Force, May 2014. [Online].Available: http://www.ietf.org/rfc/rfc7228.txt

[3] HP Fortify On Demand, “Report internet of things researchstudy,” h30499.www3.hp.com/hpeb/attachments/hpeb/application-security-fortify-on-demand/189/1/HP IoTResearch Study.pdf, July 2014.

[4] N. Modadugu and E. Rescorla, “The design and implemen-tation of datagram tls,” in Proc. of NDSS’04, 2004.

[5] H. C. Pohls, V. Angelakis, S. Suppan, K. Fischer,G. Oikonomou, E. Z. Tragos, R. D. Rodriguez, andT. Mouroutis, “Rerum: Building a reliable iot upon privacy-and security- enabled smart objects,” in Proc. of the IEEEWCNC 2014 Workshop on Internet of Things Communicationsand Technologies. IEEE, 2014.

[6] Zolertia, “Z1 product,” http://zolertia.com/products/z1, 2015.

[7] Postscapes Labs, “Internet of Things Protocols and Stan-dards,” http://postscapes.com/internet-of-things-protocols,2015.

[8] D. Engels, X. Fan, G. Gong, H. Hu, and E. M. Smith,“Hummingbird: ultra-lightweight cryptography for resource-constrained devices,” in Financial Cryptography and DataSecurity. Springer, 2010, pp. 3–18.

[9] J. Ayuso, L. Marin, A. Jara, and A. F. G. Skarmeta, “Opti-mization of public key cryptography (rsa and ecc) for 16-bitsdevices based on 6lowpan,” in 1st International Workshop onthe Security of the Internet of Things, Tokyo, Japan, 2010.

[10] V. Miller, “Use of elliptic curves in cryptography,” in Ad-vances in CryptologyCRYPTO85 Proceedings. Springer,1986, pp. 417–426.

[11] N. Koblitz, “Elliptic curve cryptosystems,” Mathematics ofcomputation, vol. 48, no. 177, pp. 203–209, 1987.

[12] National Institute of Standards and Technology (NIST), “PUBFIPS 186-4. Digital signature standard (DSS),” 2011.

[13] A. Liu and P. Ning, “Tinyecc: A configurable library forelliptic curve cryptography in wireless sensor networks,” inInformation Processing in Sensor Networks, 2008. IPSN’08.International Conference on. IEEE, 2008, pp. 245–256.

[14] P. Szczechowiak, L. B. Oliveira, M. Scott, M. Collier, andR. Dahab, “Nanoecc: Testing the limits of elliptic curve cryp-tography in sensor networks,” in Wireless sensor networks.Springer, 2008, pp. 305–320.

[15] National Institute of Standards and Technology (NIST),“ecc-light-certificate Library,” https://github.com/nist-emntg/ecc-light-certificate, 2014.

[16] T. Kern and M. Feldhofer, “Low-resource ECDSA implemen-tation for passive RFID tags,” in 17th IEEE InternationalConference on Electronics, Circuits, and Systems (ICECS’10).IEEE, 2010, pp. 1236–1239.

[17] M. Braun, E. Hess, and B. Meyer, “Using elliptic curves onRFID tags,” International Journal of Computer Science andNetwork Security, vol. 2, pp. 1–9, 2008.

[18] D. J. Bernstein, T. Chou, C. Chuengsatiansup, A. Hulsing,T. Lange, R. Niederhagen, and C. van Vredendaal, “Howto manipulate curve standards: a white paper for the blackhat,” Cryptology ePrint Archive, Report 2014/571, Tech. Rep.,2014.

[19] N. Moeller and S. Josefsson, “IETF Draft:EdDSA and Ed25519,” https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-02, Feb. 2015.

[20] Atmel Corporation, “ECC-based Devices,” http://www.atmel.com/products/security-ics/cryptoauthentication/ecc-256.aspx,2015.

[21] Openmote.org, “Openmote CC2538,” http://www.openmote.com/hardware/openmote-cc2538-en.html, 2014.

[22] Zolertia, “Zolertia ReMote,” http://zolertia.io/product/hardware/re-mote, 2015.

[23] Eastlake, Reagle, and Solo, “XML-signaturesyntax and processing. W3C recommendation,”www.w3.org/TR/xmldsig-core/, Feb. 2002.

[24] J. Boyer, “Canonical XML V 1.0,” www.w3.org/TR/2001/REC-xml-c14n-20010315, Mar. 2001.

[25] P. Gutmann, “Why XML Security is Broken,” www.cs.auckland.ac.nz/∼pgut001/pubs/xmlsec.txt, Oct. 2004.

[26] J. Ernst, “So what about really simple XML Signatures?”netmesh.info/jernst/Technical/really-simple-xml-signatures.html [Last retrieved 2007.12.09], Feb. 2006.

[27] M. McIntosh and P. Austel, “XML signature element wrap-ping attacks and countermeasures,” in Proceedings of Work-shop on Secure Web Services, 2005.

[28] H. C. Pohls, D. Tran, F. Petersen, and F. Pscheid, “MS Office2007: Digital signature does not protect meta-data,” www.securityfocus.com/archive/1/484919/30/0/, Dec. 2007.

[29] T. Bray, “The javascript object notation (json) data inter-change format,” 2014.

[30] M. Jones, J. Bradley, and N. Sakimura, “IETF draft:JSON Web Signatures (JWS),” https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41, Jan. 2015.

[31] M. Jones, “IETF draft: JSON Web Algortihms (JWA),” https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40,Jan. 2015.

[32] M. Sporny, “Secure messaging vs. javascript object signingand encryption,” http://manu.sporny.org/2013/sm-vs-jose/,Aug. 2013.

[33] C. Bormann and P. Hoffman, “Concise Binary ObjectRepresentation (CBOR),” RFC 7049, Internet EngineeringTask Force, 2013. [Online]. Available: https://tools.ietf.org/html/rfc7049

[34] C. Bormann, “IETF draft: CBOR Object Signingand Encryption (COSE),” https://tools.ietf.org/html/draft-bormann-jose-cose-00, Oct. 2014.

[35] J. Schaad, “IETF draft: CBOR Encoded Message Syntax,”http://www.ietf.org/id/draft-schaad-cose-01.txt, April 2015.

[36] A. Rundgren, “JSON Cleartext Signature (JCS),”https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html, Jan. 2015.

[37] One Laptop per Child (”OLPC”), “Canonical JSON,” http://wiki.laptop.org/go/Canonical JSON, Feb 2015.

[38] G. Staykov and J. Hu, “IETF draft: JSON Canon-ical Form,” http://www.ietf.org/archive/id/draft-staykov-hu-json-canonical-form-00.txt, Nov. 2012.

[39] A. Dunkels et al., “The contiki operating system,” http://www.contiki-os.org/, 2015.