Hi, we are using an AVR RZRAVEN USB stick to sniff the traffic sent between TelosB motes running TinyOS 2.1.1. The traffic is encrypted using the hardware AES-encryption provided by the CC2420 transceiver. The problem is, I am unable to successfully decrypt the packets, even though I know the key and all (almost; see below) information for constructing the IV/nonce. For verification, I use the openssl command by specifying the appropriate 'iv' and 'K' parameters.
According to the CC2420 data sheet [1] (Table 7, page 45) the nonce consists of flags, EUI64 source address, frame counter, key sequence counter and block counter. Going through the fields, here are the issues I am facing: 1) TinyOS sets the flags to 0x01. Why does it not set the flags according to the data sheet? 2) TinyOS does not use a EUI64 address. In the TinyOS sources, I can see that it sets this address field to all 0's. 3) I assume the 'key sequence counter' is just the *index* of the key used for encryption. So this value should either be 0 or 1. But then, why does TinyOS always set this to 0? 4) TinyOS also seems to set the block counter to 0x0001. According to IEEE 802.15.4-2003 (7.6.2.2, page 173), this should be set to 0 for the first block. These issues raise the question, if there are things going on inside the CC2420 chip, which TinyOS does not have control over. For one thing, the CC2420 data sheet is not very explicit about which information has to be filled in by software and which fields are overwritten by the chip. To my understanding, only the block counter is set by the chip. On the other hand, attempts to decrypt the payload with a source address of all 0's, the correct frame counter and key index (as given in the header) and a block counter of 0 or 1 and all possible variations for the flags field, have failed. As far as I can see, the only reason for failure can be some 64bit source address I am not aware of. Consequently, I tried reading out the IEEEADR value from the CC2420 RAM. But after each reset, this gave slightly different values, suggesting that the value in there is garbage (it is not set by TinyOS either, according to the sources). Can someone please shed some light on this? Note that the traffic can successfully be decrypted by other TinyOS motes. So given knowledge about the key and all packet bytes only, the mote is able to construct a valid nonce value. [1] http://focus.ti.com/lit/ds/swrs041b/swrs041b.pdf Kind regards, -- Jakob Bieling, Computer Science 4, University of Bonn _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
