Changes between Version 15 and Version 16 of SCU


Ignore:
Timestamp:
Oct 6, 2010, 9:55:04 AM (14 years ago)
Author:
fornasiero
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SCU

    v15 v16  
    1515
    1616There are mainly three security aspects to be considered in the desing of a Secure Code Update (SCU) mechanism. First, a SCU mechanism shall only allow the load of authentic code images into the nodes' memory. Second, a SCU mechanism must detect the dissemination of a modified or corrupted code image as early as possible. The need is to avoid unnecessary energy consumption due to the propagation of a corrupted image over multiple hops and to the re-transmission of its pages. Finally, a SCU mechanism must keep the secrecy of a code image being disseminated. The need is to prevent eavesdroppers from gaining information on the content of the code image.
    17 
    18 == Architectural Overview ==
    1917
    2018== Installation ==
     
    3028We assume that the installation PC is running a '''Linux''' operating system  and the [http://docs.tinyos.net/index.php/Getting_started TinyOS-2.x] has been installed and configured properly on it. We skip the installation of TinyOS here and refer to [http://docs.tinyos.net/index.php/Getting_started TinyOS-2.x] if needed. We describe the installation and configuration steps in the following for the [http://www.ubuntu.com/ Ubuntu] operating system.
    3129
    32 These is the structure of the files contained in the SCU software package:
     30This is the structure of the content of the SCU software package:
    3331* scu
    34  * lib: Contains Bouncy Castle java library
    35  * scu-contrib: Contains developed TinyOS code for Secure Code Update
    36  * tinyos-2.x: Contains a minimal TinyOS source tree, necessary for compilation and running of the developed software
    37  * init_variables.sh: Inits environment variables
    38  * quick_start.sh: Simple script that execute a guided step-by step deployment, followed by a Secure Code Update operation.
     32 * lib\\ Contains Bouncy Castle java library
     33 * scu-contrib\\ Contains developed TinyOS code for Secure Code Update
     34 * tinyos-2.x\\ Contains a minimal TinyOS source tree, necessary for compilation and running of the developed software
     35 * init_variables.sh\\ Inits environment variables
     36 * quick_start.sh\\ Simple script that execute a guided step-by step deployment, followed by a Secure Code Update operation.
    3937
    4038
     
    4240
    4341
    44 === Shortest HOWTO:
     42=== Shortest HOWTO
    4543
    4644Execute quick_start.sh and follow instructions.
     
    4846
    4947
    50 === Short HOWTO:
     48=== Short HOWTO
    5149
    5250* First of all, open a shell console in this folder and init the environment variables executing
    5351{{{
    54         source init_variables.sh
     52source init_variables.sh
    5553}}}
    5654* Then you can compile the tools used for Secure Code Update, executing
    5755{{{
    58         java net.tinyos.signet.SecureSynapseInterface -compile-tools
    59 }}}
    60 * Now the nodes of the network can be deployed,  i.e., the keys necessary for security operations must be installed in the nodes' external flash memory, and the Synapse bootloader along with SecureSynapse must be installed in the nodes' application flash memory. The command to execute is
    61 {{{
    62         java net.tinyos.signet.SecureSynapseInterface -deploy <auth. security param.> <T-TimeSA T parameter> <encryption security param> <DoS protection security param> [-keep-keys] [-use-authentication] [-use-encryption] [-use-dos-protection]
     56java net.tinyos.signet.SecureSynapseInterface -compile-tools
     57}}}
     58* Now the nodes of the network can be deployed,  i.e., the keys necessary for security operations must be installed in the nodes' external flash memory, and the Synapse bootloader along with !SecureSynapse must be installed in the nodes' application flash memory. The command to execute is
     59{{{
     60java net.tinyos.signet.SecureSynapseInterface -deploy <auth. security param.> <T-TimeSA T parameter> <encryption security param> <DoS protection security param> [-keep-keys] [-use-authentication] [-use-encryption] [-use-dos-protection]
    6361}}}
    6462        A typical setting is {{{ -deploy 80 30 128 128 -use-authentication -use-encryption -use-dos-protection}}}.
     
    7068* Now all nodes can be disconnected from the pc, keeping the base station connected. If more than 1 nodes are connected, the one with the minimum serial number will be used as a base station. The command to execute in order to start the dissemination is
    7169{{{     
    72         java net.tinyos.signet.SecureSynapseInterface -dissem <application path> <block size> <application id> [-use-key-refresh [-low-overhead]] [-format-nodes] [-format-bs] [-use-authentication] [-use-encryption] [-use-dos-protection]
     70java net.tinyos.signet.SecureSynapseInterface -dissem <application path> <block size> <application id> [-use-key-refresh [-low-overhead]] [-format-nodes] [-format-bs] [-use-authentication] [-use-encryption] [-use-dos-protection]
    7371}}}
    7472        Block size MUST currently be set to 800 to match Synapse configuration. Application path points to the directory containing the "build" directory of the application to disseminate. Application ID is a hexadecimal, 16-bit long, user-defined ID. If {{{-use-key-refresh}}} option is given, some keys are disseminated in order to replace the keys used for the signature. If {{{-low-overhead}}} option is given, just a fraction of the keys are updated, in order to minimize the overhead.
     
    7775        So a typical setting for the first invocation of this command is
    7876{{{
    79         java net.tinyos.signet.SecureSynapseInterface -dissem <app path> 800 1 -format-bs -format-nodes -use-authentication -use-encryption -use-dos-protection
    80 }}}
    81         The application to disseminate will be transfered to the base station node, SecureSynapse will be installed and first of all the nodes will be formatted, then the dissemination will start. When the dissemination finishes, the disseminated application will be loaded.
     77java net.tinyos.signet.SecureSynapseInterface -dissem <app path> 800 1 -format-bs -format-nodes -use-authentication -use-encryption -use-dos-protection
     78}}}
     79        The application to disseminate will be transfered to the base station node, !SecureSynapse will be installed and first of all the nodes will be formatted, then the dissemination will start. When the dissemination finishes, the disseminated application will be loaded.
    8280
    8381
    8482=== Detailed HOWTO
    8583       
    86 SecureSynapseInterface is just a high-level interface that manages in a parallel fashion all nodes connected to the pc.
     84!SecureSynapseInterface is just a high-level interface that manages in a parallel fashion all nodes connected to the pc.
    8785Lower level control tools are:
    8886
    89 * Java application: net.tinyos.signet.SynapseKeyStorage
    90 * Java application: net.tinyos.signet.KeyVolumeManagerClient
    91 * Java application: net.tinyos.signet.FlashManagerClient
     87* Java application: net.tinyos.signet.!SynapseKeyStorage
     88* Java application: net.tinyos.signet.!KeyVolumeManagerClient
     89* Java application: net.tinyos.signet.!FlashManagerClient
    9290* Java application: net.tinyos.signet.SecurityTaggerV0
    9391* Java application: net.tinyos.signet.SecurityEncrypterV0
     
    9997
    10098
    101 ==== SynapseKeyStorage tool
     99==== !SynapseKeyStorage tool
    102100
    103101This tool manages the private key storage and permits to export the public keys. This tool generates and uses the configuration file "$HOME/synapse-config.txt". The invocation syntax is the following:
     
    105103 java net.tinyos.signet.SynapseKeyStorage [-generate <# of security bits for authentication> <#of uses per key> <# of security bits for encryption> <# of security bits for DoS protection> <filename>] [-get-public <key storage filename> <destination filename>]
    106104}}}
    107 If the "generate" option is given, the private keys are generated, depending on the given security parameters and stored in the given file.
    108 If the "get-public" options is given, the public keys are generated from the private keys and stored in the given file.
     105If the {{{-generate}}} option is given, the private keys are generated, depending on the given security parameters and stored in the given file.
     106If the {{{-get-public}}} options is given, the public keys are generated from the private keys and stored in the given file.
    109107
    110108Typically the command is invoked as following
     
    114112}}}
    115113
    116 ==== KeyVolumeManagerClient tool
    117 
    118 This tool is used to store and retrieved keys from the nodes' flash memory, communicating with the TinyOS application KeyVolumeManager, which must be installed on the node in order to use this tool. The invocation syntax is the following:
     114==== !KeyVolumeManagerClient tool
     115
     116This tool is used to store and retrieve keys from the nodes' flash memory, communicating with the TinyOS application !KeyVolumeManager, which must be installed on the node in order to use this tool. The invocation syntax is the following:
    119117{{{
    120118 java net.tinyos.signet.KeyVolumeManagerClient [-comm <source>] [-verbose] [-progress] [-upload <public key file>] [-download <output file>]
    121119}}}
    122 If the "upload" option is given, the public keys contained in the given file are uploaded in the node.
    123 If the "download" option is given, the public keys contained in the node are downloaded in the given file.
     120If the {{{-upload}}} option is given, the public keys contained in the given file are uploaded in the node.
     121If the {{{-download}}} option is given, the public keys contained in the node are downloaded in the given file.
    124122
    125123An example of invocation is the following
     
    128126}}}
    129127
    130 ==== FlashManagerClient tool
    131 
    132 This tool is used to format, store and retrieve applications from the nodes' flash memory. This tool communicates with the TinyOS application FlashManager, which must be installed on the node in order to use this tool. The invocation syntax is the following:
     128==== !FlashManagerClient tool
     129
     130This tool is used to format, store and retrieve applications from the nodes' flash memory. This tool communicates with the TinyOS application !FlashManager, which must be installed on the node in order to use this tool. The invocation syntax is the following:
    133131{{{
    134132 java net.tinyos.signet.FlashManagerClient [-comm <source>] [-verbose] [-progress] [-print-table] [-format] [-readid <partition ID,4 digits radix 16> <output file>] [-writefile <desired partition ID, 4 digits radix 16> <local filename> <program start offset radix, 4 digits radix 16>]
    135133}}}
    136134
    137 If the "print-table" option is given, then the partition table is printed on standard output.
    138 If the "format" option is given, then the node's flash is formatted.
    139 If the "readid" option is given, then the partition with given ID is read and stored in the given file.
    140 If the "writefile" option is given, then the given file is stored in a new partition with the given ID. Multiple partition with the same ID can coexists on the node's flash memory, and the last will be always used when required. The program start offset indicates the offset at the beginning of the file where the executable code starts (this is useful when the security tags are prefixed to the application code).
     135If the {{{-print-table}}} option is given, then the partition table is printed on standard output.
     136If the {{{-format}}} option is given, then the node's flash is formatted.
     137If the {{{-readid}}} option is given, then the partition with given ID is read and stored in the given file.
     138If the {{{-writefile}}} option is given, then the given file is stored in a new partition with the given ID. Multiple partition with the same ID can coexists on the node's flash memory, and the last will be always used when required. The program start offset indicates the offset at the beginning of the file where the executable code starts (this is useful when the security tags are prefixed to the application code).
    141139
    142140
     
    147145 java net.tinyos.signet.SecurityTaggerV0 [-sign <keys filename> <block size> <inputfile> <outputfile> [-update-keys [-low-overhead]] [-use-key-refresh] ]
    148146}}}
    149 The only command executable with this tool is the "sign" command. The "keys filename" parameter is the name of the file containing the private keys (i.e. the one generated with the SynapseKeyStorage tool). Block size must be 800, as defined in the Synapse application. Inputfile is the file containing the binary code of the application. This file is obtained using the ihex_to_binary script. Outputfile is the generated file.
     147The only command executable with this tool is the {{{-sign}}} command. The {{{<keys filename>}}} parameter is the name of the file containing the private keys (i.e. the one generated with the !SynapseKeyStorage tool). Block size must be 800, as defined in the Synapse application. Inputfile is the file containing the binary code of the application. This file is obtained using the ihex_to_binary script. Outputfile is the generated file.
    150148
    151149==== SecurityEncrypterV0 tool
     
    165163Commands description:
    166164* Prepare: stops dissemination, prepares the network for other commands as format, reset or load.
    167 * Format: all nodes in the network (except the base station) format their flash memory (Synapse is then re-stored). Use FlashManager to format the base station.
     165* Format: all nodes in the network (except the base station) format their flash memory (Synapse is then re-stored). Use !FlashManager to format the base station.
    168166* Reset: all nodes in the network reboot.
    169167* Load: all nodes in the network (except the base station) load the application corresponding to the given id.
     
    184182 get_tags_size.sh <tagged file> <untagged file>
    185183}}}
    186 where <untagged file> usually is the application binary file, and <tagged file> is the file obtained using the SecurityTaggerV0 tool.
    187 This tool simply calculates the difference between the size of these two files, to obtain the size of the security tags. This size can then be used as the parameter to provide to the FlashManager tool.
     184where {{{<untagged file>}}} usually is the application binary file, and {{{<tagged file>}}} is the file obtained using the SecurityTaggerV0 tool.
     185This tool simply calculates the difference between the size of these two files, to obtain the size of the security tags. This size can then be used as the parameter to provide to the !FlashManager tool.
    188186
    189187