Re: [Tinyos-help] mig issue failed parsing RssiDemoMessages.h
Hi George, I do not have a solution, but I thought I'd share our findings. We are facing the same problem on Ubuntu 11. But the identical code compiles on Debian5 and Ubuntu 10 machines. The error we get is similar to yours, but not identical: two source files specified (PLATFORM_NULL and TOSH_DATA_LENGTH=100) .. Due to time constraints, we did not dig deeper into this, as we are able to take the class files from the Debian machine. But maybe this info helps you find the actual cause of the error. Best, Jakob On Nov 7, 2011, at 3:08 PM, George Smart wrote: > Hi. I am trying to build the Java program to go with the RssiDemo. I > have all the nodes programmed and can read binary data from the nodes > via terminal program. When it comes to running the Java PC program, I > just can't seem to get it to compile! I get the following errors: > > george@box:/opt/tinyos-2.1.1/apps/tutorials/RssiDemo/java$ sudo make > mig java -target=null -java-classname=RssiMsg ../RssiDemoMessages.h > RssiMsg -o RssiMsg.java > two source files specified (PLATFORM_NULL and NESC=131) > failed to parse message file ../RssiDemoMessages.h > make: *** [RssiMsg.java] Error 1 > george@box:/opt/tinyos-2.1.1/apps/tutorials/RssiDemo/java$ > > I just don't have enough experience to fix it. If anyone can offer any > suggestions, that would be great. I'm running Ubuntu 11.10, 64-bit with > the proper Oracle Java 7 suite. I had a good around and a search this > mailing list but I couldn't find an answer to this. > > Thanks in Advance. > > George Smart > Ph.D Student, E&EE, UCL. -- net.cs.bonn.edu/bieling signature.asc Description: Message signed with OpenPGP using GPGMail ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Loading / saving a array of uint8_t at micaz/iris nodes
On Jul 26, 2011, at 6:27 PM, Michael Schippling wrote: > I don't know if there is any erase of external EEPROM done > when a device is programmed, so the contents _might_ persist > across new downloads and thus you would only have to do > the message thing once. It does indeed persist, at least to my empirical knowledge. You will have to explicitly erase the flash, if you really want it erased. Also, afaik, you _must_ erase it the first time you use a new volumes-xyz.xml layout file. Not sure what happens if you don't, but I think that's what the docs said .. Best, Jakob > Markus Niedermann wrote: >> Hey! >> Im using tinyos 2.1.1 at micaZ and iris nodes. >> >> I use ECDH to get a secret key for a symmetric encryption between nodes >> and with the PC. >> For saving time, I pregenerate my public / private keys at the PC. >> First, I hard-coded them as uint8_t- arrays in the code. >> The configuration is should be installed at different nodes with >> different keys. >> Now I want to save the 160-bit-keys at the external flash of my nodes. >> How should I handle this? >> The TinyOS-Page seems to be partially offline, so I can't get all >> Information I need. >> >> http://docs.tinyos.net/tinywiki/index.php/Storage >> I read this tutorial. >> I'm not quite sure how I have to configure the xml file. >> >> I guess I have to write a second application, that I use to save the >> keys on my nodes, right? Or is there a way to save something directly >> over the serial interface? -- net.cs.bonn.edu/bieling ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Standalone AES Encryption of CC2420 - How to decrypt?
Hi again,
one more follow-up. I mixed up on-the-fly encryption with standalone
encryption:
- standalone encryption on the CC2420 really allows encryption only and does
not use CTR mode, ie. if you encrypt data, you cannot decrypt it, unless you
use a specific cipher mode (like CTR)
- on-the-fly encryption uses CTR mode and here the process for encrypting and
decrypting is the same (tho you would not have to care about that, since the
chip does pretty much everything for you)
This means, you can use the standalone encryption only in cipher modes like
CTR, where only the encryption process is needed. Consequently, you will have
to implement your own CTR mode, if you want to be able to decrypt your data. If
you are not familiar with CTR, Wikipedia is a good place to start.
Best,
Jakob
On Jun 2, 2011, at 10:17 AM, Jakob Bieling wrote:
> Hi,
>
> On Jun 2, 2011, at 10:02 AM, Damian Rusinek wrote:
>> Unfortunately encrypting the ciper again does not decrypt it.
>
> In the sample code, try setting the plain text to
>
> uint8_t aes_plaintext[16] = {
>0x69, 0xc4, 0xe0, 0xd8, 0x6a, 0x7b, 0x04, 0x30,
>0xd8, 0xcd, 0xb7, 0x80, 0x70, 0xb4, 0xc5, 0x5a,
> };
>
> and check what the encrypted text is. Make sure the rest of the sample code
> is unchanged!
>
>> To
>> decrypt, you need to provide generated keys in inverted order. That's
>> what I want to achieve.
>
> I am not sure what you mean by that. In general, the CC2420 needs inversion
> of the key-bytes, because the key is read like that (i.e., backwards) into
> RAM. But this affects encryption as well as decryption and is already done by
> that library. You should not need to invert anything.
>
> Best,
> Jakob
>
>
>> 2011/6/2 Jakob Bieling :
>>> try "encryting" the cipher text again. The CC2420 AES works in CTR mode,
>>> meaning encryption and decryption are the same operation.
>>>
>>> Moreover, if you send your packets anyway, you can use the built-in
>>> functionality of the CC2420 chip to encrypt all outgoing packets on the
>>> fly. It will also decrypt incoming packets automatically. TinyOS already
>>> allows for this, simply Google for "tinyos cc2420 security tutorial". Note
>>> that the actual wiki seems to be down, but you use the Google cache. That
>>> worked for me.
>>>
>>> On Jun 2, 2011, at 9:07 AM, Damian Rusinek wrote:
>>>
>>>> Hello.
>>>> I'm using 'The Standalone AES Encryption of CC2420' which is described
>>>> here:
>>>> http://cis.sjtu.edu.cn/index.php/The_Standalone_AES_Encryption_of_CC2420_(TinyOS_2.10_and_MICAz)
>>>>
>>>> I encrypt the payload of my packet before sending.
>>>> The question is how can I decrypt it?
>>>> Does anybody use this library?
> --
> net.cs.bonn.edu/bieling
>
>
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
net.cs.bonn.edu/bieling
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Standalone AES Encryption of CC2420 - How to decrypt?
Hi,
On Jun 2, 2011, at 10:02 AM, Damian Rusinek wrote:
> Unfortunately encrypting the ciper again does not decrypt it.
In the sample code, try setting the plain text to
uint8_t aes_plaintext[16] = {
0x69, 0xc4, 0xe0, 0xd8, 0x6a, 0x7b, 0x04, 0x30,
0xd8, 0xcd, 0xb7, 0x80, 0x70, 0xb4, 0xc5, 0x5a,
};
and check what the encrypted text is. Make sure the rest of the sample code
is unchanged!
> To
> decrypt, you need to provide generated keys in inverted order. That's
> what I want to achieve.
I am not sure what you mean by that. In general, the CC2420 needs inversion
of the key-bytes, because the key is read like that (i.e., backwards) into RAM.
But this affects encryption as well as decryption and is already done by that
library. You should not need to invert anything.
Best,
Jakob
> 2011/6/2 Jakob Bieling :
>> try "encryting" the cipher text again. The CC2420 AES works in CTR mode,
>> meaning encryption and decryption are the same operation.
>>
>> Moreover, if you send your packets anyway, you can use the built-in
>> functionality of the CC2420 chip to encrypt all outgoing packets on the fly.
>> It will also decrypt incoming packets automatically. TinyOS already allows
>> for this, simply Google for "tinyos cc2420 security tutorial". Note that the
>> actual wiki seems to be down, but you use the Google cache. That worked for
>> me.
>>
>> On Jun 2, 2011, at 9:07 AM, Damian Rusinek wrote:
>>
>>> Hello.
>>> I'm using 'The Standalone AES Encryption of CC2420' which is described
>>> here:
>>> http://cis.sjtu.edu.cn/index.php/The_Standalone_AES_Encryption_of_CC2420_(TinyOS_2.10_and_MICAz)
>>>
>>> I encrypt the payload of my packet before sending.
>>> The question is how can I decrypt it?
>>> Does anybody use this library?
--
net.cs.bonn.edu/bieling
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Standalone AES Encryption of CC2420 - How to decrypt?
Hi, try "encryting" the cipher text again. The CC2420 AES works in CTR mode, meaning encryption and decryption are the same operation. Moreover, if you send your packets anyway, you can use the built-in functionality of the CC2420 chip to encrypt all outgoing packets on the fly. It will also decrypt incoming packets automatically. TinyOS already allows for this, simply Google for "tinyos cc2420 security tutorial". Note that the actual wiki seems to be down, but you use the Google cache. That worked for me. Best, Jakob On Jun 2, 2011, at 9:07 AM, Damian Rusinek wrote: > Hello. > I'm using 'The Standalone AES Encryption of CC2420' which is described > here: > http://cis.sjtu.edu.cn/index.php/The_Standalone_AES_Encryption_of_CC2420_(TinyOS_2.10_and_MICAz) > > I encrypt the payload of my packet before sending. > The question is how can I decrypt it? > Does anybody use this library? -- net.cs.bonn.edu/bieling ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] telosb size problem
On May 11, 2011, at 9:44 PM, Eric Decker wrote: > Now what exactly are you doing? I assume that ECC is error correction. But > what are you protecting and such. Details please. I used to do Information > Theory. Just curious as to what you are working on. Thanks. I assumed it was elliptic curve cryptography. At this point I might have mentioned, that the OP could have used TinyECC for that purpose. Best, Jakob -- net.cs.bonn.edu/bieling ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] telosb size problem
Hi, it means your image is too large, it will not fit on the mote. Best, Jakob On May 11, 2011, at 6:26 PM, euchi Manel wrote: > hi, > i try to integrate ECC in my application but when i do" make telosb install" > i find this error: > > (msp430-ld: region text is full (build/telosb/main.exe section .text) > msp430-ld: section .vectors [ffe0 -> ] overlaps section .text > [4 > 000 -> 000118fb] > msp430-ld: build/telosb/main.exe: section .vectors lma 0xffe0 overlaps > previous > sections) > > Does anyone have any idea how to solve this? > I would really appreciate the help I get! > > Regards -- net.cs.bonn.edu/bieling ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] cc2420 security questions
On May 10, 2011, at 1:49 AM, Viktor Zsoldos wrote: > - I've installed the BaseStation from apps/tests/cc2420/TestSecurity, and > trying to read the secured traffic with net.tinyos.tools.Listen, but only > ordinary headers are showing (dst, src, len, gID, hID), I can't see any > CC2420 or security related headers. They must be there, since I can read out > e.g. the frameCounter field from security_header_t with a mote, and put the > value to LEDs. What's the trick? Try modifying the BaseStation such that it also reads out the security_header_t directly (as you did with other motes) . I assume the BaseStation just doesn't forward the header, but it's there. > - With CBC-MAC mode if I change the key value of the sender mote, the > receiver will still happily accept the packet with the wrong MAC. Do I have > to > generate the MAC at the receiver manually to check if it equals to the > received one? The CC2420 chip sets the last byte of the MAC according to the verification result. If I recall correctly, 0x00 = MIC ok, else MIC not ok. Best, Jakob -- net.cs.bonn.edu/bieling ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Unable to decrypt CC2420 AES packets "manually"
Hi again, just reporting back, the problem is solved. For one, there was an error decrypting the packets by hand. I am not sure what it was, but other than having used a wrong key after all I cannot see what else could have gone wrong. The ultimate problem was Wireshark not being able to decrypt our packets. This was solved by replacing the libcrypto AES code with FIPS-compatible code. Seems like the libcrypto decryption routines do something slightly different, leading to completely different results. Regarding the issues below, it turns out that the IV specified by TinyOS is indeed the one you see in the source (with the block counter set by the CC2420 chip). Consequently, you cannot use the IV specified by IEEE 802.15.4 but need to account for the IV TinyOS is using. Best, Jakob On Jan 7, 2011, at 10:16 AM, Jakob Bieling wrote: > 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 -- 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
[Tinyos-help] Unable to decrypt CC2420 AES packets "manually"
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
