Changes between Version 15 and Version 16 of SCU
- Timestamp:
- Oct 6, 2010, 9:55:04 AM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SCU
v15 v16 15 15 16 16 There 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 ==19 17 20 18 == Installation == … … 30 28 We 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. 31 29 32 Th ese is the structure of the files contained inthe SCU software package:30 This is the structure of the content of the SCU software package: 33 31 * scu 34 * lib :Contains Bouncy Castle java library35 * scu-contrib :Contains developed TinyOS code for Secure Code Update36 * tinyos-2.x :Contains a minimal TinyOS source tree, necessary for compilation and running of the developed software37 * init_variables.sh :Inits environment variables38 * 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. 39 37 40 38 … … 42 40 43 41 44 === Shortest HOWTO :42 === Shortest HOWTO 45 43 46 44 Execute quick_start.sh and follow instructions. … … 48 46 49 47 50 === Short HOWTO :48 === Short HOWTO 51 49 52 50 * First of all, open a shell console in this folder and init the environment variables executing 53 51 {{{ 54 52 source init_variables.sh 55 53 }}} 56 54 * Then you can compile the tools used for Secure Code Update, executing 57 55 {{{ 58 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 is61 {{{ 62 56 java 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 {{{ 60 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] 63 61 }}} 64 62 A typical setting is {{{ -deploy 80 30 128 128 -use-authentication -use-encryption -use-dos-protection}}}. … … 70 68 * 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 71 69 {{{ 72 70 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] 73 71 }}} 74 72 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. … … 77 75 So a typical setting for the first invocation of this command is 78 76 {{{ 79 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.77 java 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. 82 80 83 81 84 82 === Detailed HOWTO 85 83 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. 87 85 Lower level control tools are: 88 86 89 * Java application: net.tinyos.signet. SynapseKeyStorage90 * Java application: net.tinyos.signet. KeyVolumeManagerClient91 * Java application: net.tinyos.signet. FlashManagerClient87 * Java application: net.tinyos.signet.!SynapseKeyStorage 88 * Java application: net.tinyos.signet.!KeyVolumeManagerClient 89 * Java application: net.tinyos.signet.!FlashManagerClient 92 90 * Java application: net.tinyos.signet.SecurityTaggerV0 93 91 * Java application: net.tinyos.signet.SecurityEncrypterV0 … … 99 97 100 98 101 ==== SynapseKeyStorage tool99 ==== !SynapseKeyStorage tool 102 100 103 101 This 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: … … 105 103 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>] 106 104 }}} 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.105 If the {{{-generate}}} option is given, the private keys are generated, depending on the given security parameters and stored in the given file. 106 If the {{{-get-public}}} options is given, the public keys are generated from the private keys and stored in the given file. 109 107 110 108 Typically the command is invoked as following … … 114 112 }}} 115 113 116 ==== KeyVolumeManagerClient tool117 118 This tool is used to store and retrieve d keys from the nodes' flash memory, communicating with the TinyOS applicationKeyVolumeManager, which must be installed on the node in order to use this tool. The invocation syntax is the following:114 ==== !KeyVolumeManagerClient tool 115 116 This 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: 119 117 {{{ 120 118 java net.tinyos.signet.KeyVolumeManagerClient [-comm <source>] [-verbose] [-progress] [-upload <public key file>] [-download <output file>] 121 119 }}} 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.120 If the {{{-upload}}} option is given, the public keys contained in the given file are uploaded in the node. 121 If the {{{-download}}} option is given, the public keys contained in the node are downloaded in the given file. 124 122 125 123 An example of invocation is the following … … 128 126 }}} 129 127 130 ==== FlashManagerClient tool131 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 130 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: 133 131 {{{ 134 132 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>] 135 133 }}} 136 134 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).135 If the {{{-print-table}}} option is given, then the partition table is printed on standard output. 136 If the {{{-format}}} option is given, then the node's flash is formatted. 137 If the {{{-readid}}} option is given, then the partition with given ID is read and stored in the given file. 138 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). 141 139 142 140 … … 147 145 java net.tinyos.signet.SecurityTaggerV0 [-sign <keys filename> <block size> <inputfile> <outputfile> [-update-keys [-low-overhead]] [-use-key-refresh] ] 148 146 }}} 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 theSynapseKeyStorage 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.147 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. 150 148 151 149 ==== SecurityEncrypterV0 tool … … 165 163 Commands description: 166 164 * 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. 168 166 * Reset: all nodes in the network reboot. 169 167 * Load: all nodes in the network (except the base station) load the application corresponding to the given id. … … 184 182 get_tags_size.sh <tagged file> <untagged file> 185 183 }}} 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.184 where {{{<untagged file>}}} usually is the application binary file, and {{{<tagged file>}}} is the file obtained using the SecurityTaggerV0 tool. 185 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. 188 186 189 187