Shahidraza.info

Ibrahim Ethem Bagci1, Mohammad Reza Pourmirza1, Shahid Raza2, Utz Roedig1, Thiemo Voigt2,3 1School of Computing and Communications, Lancaster University, Lancaster, UK {i.bagci, m.pourmirza, u.roedig}@lancaster.ac.uk 2Swedish Institute of Computer Science, Kista, Sweden Abstract—Many Wireless Sensor Networks (WSNs) are used to To secure data stored on nodes it has been proposed to collect and process confidential information. Confidentiality must simply encrypt the data before storage using key chains (see, be ensured at all times and, for example, solutions for confidential for example, [2], [3]). Such a naive approach ensures confi- communication, processing or storage are required. To date, the research community has addressed mainly the issue of confi- dentiality but at the same time restricts a node’s processing dential communication. Efficient solutions for cryptographically capability and does not consider system performance issues.
secured communication and associated key exchange in WSNs Such existing solutions do not enable nodes to access already exist. Many WSN applications, however, rely heavily on available stored data for in-network data processing on nodes and do on-node storage space and therefore it is essential to ensure not allow us to balance performance and security concerns.
the confidentiality of stored data as well. In this paper we present Codo, a confidential data storage solution which balances Furthermore, existing solutions are not tailored to hardware platform, performance and security requirements. We implement specifics such as flash memory layout or available hardware Codo for the Contiki WSN operating system and evaluate its support for cryptographic algorithms.
In this paper we present Codo, a framework for efficient confidential data storage on sensor nodes. Codo addresses the aforementioned shortcomings present in existing solutions by enabling confidential data storage and in-network data In many Wireless Sensor Networks (WSNs) sensor data is processing on nodes. Security concerns and performance can transferred immediately to a sink for further processing. In be balanced by deciding how much unencrypted data can such applications no data is stored on nodes and confidentiality be present on a node at any given point in time. To im- of stored information is not an issue. A number of (recent) prove performance, encrypted data storage is aligned with applications use, however, available on-node storage space to flash memory layout and cryptographic hardware support. The add new features or to improve network performance. For specific contributions of the paper are: example, on-node storage may be used when the network • Codo: We give a design specification of the efficient capacity is insufficient to transport all gathered data from all confidential data storage framework.
nodes to the sink. Instead, stored data is pre-processed by • Codo Implementation: We detail the implementation of nodes and only processing results are transmitted. Moreover, Codo for the Contiki OS [4] running on a Tmote Sky.
the sink may as well request processing or transmission of In particular, we show the integration of Codo with the Contiki flash file system Coffee [5].
An example of such an application is industrial process • Codo Evaluation: We evaluate the different aspects of monitoring and control [1] where sensors used to collect Codo and quantify performance implications. Where and store vast amounts of data on production processes.
possible we compare results with existing traditional Nodes process sensor data and transmit results to a sink node. At times, the sink may request to process sensor data The next section discusses related work. Section III describes over specific time periods (e.g. to calculate the average of a the proposed confidential storage framework Codo. We de- sensor reading over a recent set time period) or request all scribe our Codo implementation for the Contiki operating sampling points in a specific time period. Such specific data system in Section IV. Section V presents the evaluation of requests may be necessary for error diagnosis or to calibrate Codo and Section VI concludes the paper.
the overall production processes. As sensors store information about production processes it is of vital interest to a company to keep such information hidden from competitors. If a node is Bhatnagar and Miller [2], Pietro et al. [6] and Girao et al. [7] removed from the facility it should not be possible to retrieve present a secure and reliable file systems. All of these solutions use irreversible key generation methods which prevent nodes to access data locally. Ren et al. propose a secure, dependable sizes) and to the capabilities of the encryption hardware (e.g.
and distributed storage scheme using public key encryption to buffer size of cryptographic processor).
ensure data confidentiality [3]. Their scheme does not allow DataChunk Size: The DataChunk size SD is determined by a nodes to access stored data either. In contrast, Codo allows number of factors. These are: nodes to access stored data for processing. In addition, public • Cryptographic Algorithm: The cryptographic algorithm key cryptography requires more processing than symmetric usually operates on fixed block sizes SB. The DataChunk size should therefore be aligned with this block size.
Due to higher speed and better security (e.g. resistant to Thus, the DataChunk size SD must be a multiple of SB.
cold boot attacks) hardware based storage encryption became • Cryptographic Hardware Support: If cryptographic hard- available lately by many vendors. For example, the company ware support is available it is normally operating most Ironkey [8] manufactures secure USB flash drives in which efficiently on a block size of SC. The transfer of data to AES 256-bit encryption in CBC mode is implemented in and from the crypto processor has a fixed cost element hardware. Codo is different to these solutions as it does not (addressing, loading operations, etc.) and a variable cost element that depends on the data size to be processed.
SC is a multiple of SB and in many practical setting SC = SB. Again, SD must be a multiple of SC.
• Flash Memory: Flash memory is organized in pages of Existing security solutions focus on optimizing encryption per- P . Depending on the flash memory hardware the page size implies different constraints. For example, with formance (for example, by optimizing encryption algorithms some hardware it is only possible to read or write a whole [9] or by employing specialised cryptographic hardware [10]).
page. Other hardware allows to read or write parts of a However, performance gains that result from looking at secure page but writing or reading of complete pages is most storage from a systems perspective are largely ignored. In efficient (as the fixed cost of addressing has to be paid existing solutions data is generally encrypted as soon as it only once for all data associated with the page). It is produced (for example, in [2], [3], [6], [7]). However, for therefore reasonable to align the DataChunk size with many applications it is from a security perspective possible to cache data unencrypted before performing bulk encryption P should be therefore a multiple of SD .
and storage. Obviously, the amount of data that can be cached unencrypted will depend on the specific application.
Current solutions are hardware agnostic which leads to ineffi- ciencies. Flash memories used on sensor nodes are restricted in terms of read and write capabilities. It is often only Data Caching: To increase the performance of the system, possible to access data in chunks rather than in individual unencrypted DataChunks are cached. Write operations are bytes and it is always more efficient to process data in cached and encryption is carried out after a certain amount chunks. Thus, crypto mechanisms should operate on chunk of DataChunks are accumulated. Likewise, if previously sizes that reflect hardware capabilities. Existing solutions also stored data must be read/modified the complete corresponding ignore that hardware support for cryptographic operations DataChunk is decrypted and cached. Increasing the size of the exists on WSN nodes. Hardware support is generally available cache leads to better performance, however with this approach for secure communication but it is possible to re-use these the amount of unencrypted data present in the system would features for secure storage. Again, this cryptographic hardware be bigger. Decreasing the size of the cache leads to better is optimised for specific data chunk sizes and if used in the security, but at this time the system performance decreases.
context of storage these hardware restrictions must be taken The number of unencrypted DataChunks N system at any given time is a configuration parameter.
Key Management: In the current implementation of our frame- B. Codo: Confidential Data Storage Framework work, encryption keys are pre-shared. Future implementations Codo tackles the aforementioned limitations and shortcomings might be enhanced with dynamic key management protocols of existing confidential data storage solutions. The framework such as IKE [11].
aims to realize confidential data storage with minimal impact In our storage framework data is organised in DataChunks. Codo is implemented as an extension of Contiki’s [4] Coffee Some unencrypted data is cached to improve performance; Filesystem (CFS) [5]. CFS organizes files as a collection of depending on application security and performance needs it similar sized pages (see Figure 1) that have generally the can be decided how much unencrypted cached data can be same size as the underlying flash memory pages1. For each present. To improve performance only complete DataChunks are cryptographically processed. The size of DataChunks is It is possible to map several Contiki file system pages into one flash memory page. However, this only makes sense if the flash memory hardware matched to the capabilities of storage hardware (e.g. page is able to support operations on parts of a page.
from the file. cfs_close() (line 16) is used to close the With CFS_CRYPT, if data to be read using cfs_read() (line 9) is not yet available from the micro log file, the security manager component (see next section for details) is queried to provide the key required to decrypt the next DataChunk. The program leaves cfs_read() before completion of the read process and blocks on ev == KEY_READY. When the key is provided by the security manager a signal is sent to the waiting application process. When cfs_read() is now called again it will be able to decrypt the next data for which the key is now present. Multiple executions of cfs_read() with following PROCESS_WAIT_UNTIL may be necessary to complete one read as a sequence of different keys may be used. The call to cfs_read() with following PROCESS_WAIT_UNTIL Figure 1. The Contiki Coffee File System (CFS) (line 8 to line 12) can be combined within one C macro to hide the complexity of multiple function entries from the new file a header is created and a number of consecutive cfs_write() is used in a similar way to cfs_read().
free pages are allocated. New data is directly written to the cfs_open() supports the additional flag CFS_NO_CRYPT empty pages in the file. If pages with existing content are to indicate that a specific newly opened file should not modified a so called micro log file (also simply referred to be encrypted. Thus, the filesystem can hold encrypted and as log file) is used. For modifications a micro log file is unencrypted files at the same time.
created and linked with the original file which contains a We also add two additional functions to the CFS API: sequence of log records that have the same size as a page cfs_read_crypt() and cfs_write_crypt(). These in the original file. Each log record points to the original page two functions can be used to read and write the encrypted in the file and contains the updated information. If data is data directly. If data is still in unencrypted form in the cache accessed, the CFS checks first if newer data is available in cfs_read_crypt() will perform encryption of the data.
the log file before accessing the original file. After a certain The security manager may have to be informed to provide amount of changes the log file is filled and merged with the necessary keys and multiple calls to cfs_read_crypt() original file to form a new consolidated file. The old file and followed by PROCESS_WAIT_UNTIL might be necessary.
micro log file are marked for garbage collection. The micro These two functions are particularly useful for situations in log structure is used because the flash memory hardware does which encrypted data must be handled by the node. For not allow us to overwrite pages directly. Before overwriting example, with these functions it is possible to avoid re- a hardware page it is necessary to format and clear an entire encryption of data for data transport and the already securely erase sector containing many pages. This would be inefficient stored data can be directly placed in network packets.
when used frequently and the use of a log file reduces erase We provide a cfs_merge() which can be used to execute sector formats to a minimum performed at convenient times by the processing costly merge of file and log file at a convenient the CFS garbage collection. The CFS exposes standard func- time (for example, at times the system is idle).
tions such as cfs_open(), cfs_write(), cfs_read(), cfs_close() is modified to ensure that a merge is exe- cfs_seek() and cfs_close() to the application for cuted which makes certain that all unencrypted cached data is encrypted and stored in the file. cfs_close() may require multiple function calls with PROCESS_WAIT_UNTIL as keys may have to be organized by the security manager for To implement Codo with Contiki’s CFS it is necessary to (i) encryption.
modify and extend function calls provided by the existing CFS 2) CFS Components: library and to (ii) modify and extend the behavior of internal Micro Log: As described, the CFS uses the micro log files CFS components. We detail these necessary modifications in to handle flash memory read/write specifics. For the Codo implementation we modify the log file such that it becomes 1) CFS Function Calls : Algorithm 1 shows a simple Contiki in addition a cache holding unencrypted DataChunks. In program that uses the CFS library. The definition in line 7, 13 the standard CFS the log file is used for modifying write and 15 is used to switch the API semantic between CFS with operations. In our CFS extension also read and initial write operations are operating on the log file.
Without CFS_CRYPT a file is opened in line 6 using Whenever data is read from the file it is first checked if thecfs_open() for reading which is indicated via the flag data is present in unencrypted form in the log file. If not, CFS_READ. In line 14 cfs_read() is used to read data the key associated with the data is requested via the security Algorithm 1 A simple Contiki application program using CFS [01] PROCESS_THREAD(cfs_test_process, ev, data) { Figure 2. Writing of 2048byte in blocks of 256byte, 64byte, 32byte and The cryptographic hardware support of the Tmote’s CC2420 manager component and upon obtaining the key the data is radio chip requires a minimum block size of SC = 16byte.
decrypted and transferred to the log file. New data is always The Tmote provides an ST M25P80 flash memory with a written to the log file. When the maximum size of the log file page size of SP = 256byte. We therefore select a DataChunk is reached the log file must be cleared and merged with the size of SD = 256byte to obtain a well matched system (see Section III). We use software (CFS_CRYPT_SW) or hard- Security Manager: The security manager is implemented as ware (CFS_CRYPT_HW) supported encryption. The filesys- a Contiki thread that is responsible to (i) generate new keys tem uses a log record size of SL = 256byte to match flash if needed (ii) communicate with the sink to store and retrieve memory page size. Furthermore, the system is configured to use NL = 4 log records which means that SL·NL = 1024byte The CFS can ask the security manager via a function call for of unencrypted data can be present on the system at any given a key to a specific DataChunk of a file. This request contains point in time.
three parameters: file_id, DataChunk_id and flags. file_id is A. cfs_write() Performance the filename which is a unique identifier, DataChunk_id is the number of the DataChunk for which a key is required. flags In this first experiment a file of size 2048byte is writ- indicates if the requested key is for a portion of the file that has ten using a sequence of cfs_write() calls. With each never been used before. If this is the case the security manager cfs_write() call SW bytes are written to the file sys- has two options. First, it can create the requested key, inform tem (SW ∈ {16, 32, 64, 256}). The execution time of each the filesystem and then transmit the key to the sink for storage. cfs_write() call is measured. The experiments are re- Second, it can send a request to the sink for a new key and peated using the original CFS in append mode (CFS_APP), the when a response arrives inform the filesystem. If flags indicate original CFS in modify mode (CFS_MOD) (data is appended, that a key for a previously used DataChunk is needed and the but the file is assumed as modified and therefore also the log key is not locally present, the security manager must send a file is used), Codo CFS with software (CFS_CRYPT_SW) and hardware supported (CFS_CRYPT_HW) encryption and Codo CFS with additional RAM supported log file Cryptographic Functions: For encryption/decryption we use (CFS_CRYPT_SW_M and CFS_CRYPT_HW_M). In this ex- AES in counter mode (CTR) with 128bit key length provided periment the Security Manager holds the required key for the either by hardware (e.g. via the CC2420 radio chip present on many sensor node platforms) or by the open source MIRACL 2048byte sized file locally and there is no key exchange with the sink required. If keys are exchanged over the network key [12] library if hardware support is not available.
exchange times have to be added to the experiment results.
The experimental results are shown in Figure 2. Using CFS_APP and SW = 256byte the time to write all 2048byte to We evaluate the Codo implementation based on Contiki’s the file system is 18.3ms. In this mode the file system does not CFS using a Tmote Sky sensor node. To evaluate system make use of the log file structure and data is directly written performance we analyse the execution times of the CFS to the file structure in flash memory. With CFS_MOD the function calls. Execution times are important indicators as time increases significantly to 54.8ms as the log file structure they are a measure for system responsiveness and are directly is involved in the writing process. Each write is directed to proportional to a node’s energy consumption. Furthermore, we a log record in the log file in flash memory and when all investigate the performance of data caching when the cache is log records are filled a merge is executed to integrate log file and original file. CFS_CRYPT_SW and CFS_CRYPT_HW are WRITING OF 2048byte IN 8 BLOCKS OF 256byte.
functionally identical to CFS_MOD but when the log file is merged with the original file, encryption has to be performed. Figure 3. Reading of 2048byte in blocks of 256byte, 64byte, 32byte and Thus, with CFS_CRYPT_SW and CFS_CRYPT_HW execu- tion times are 190.8ms and 112.7ms. With RAM caching, the execution time reduces further to 151.6ms and 73.2ms (CFS_CRYPT_SW_M and CFS_CRYPT_HW_M).
The overall time of writing 2048byte to the file is not distributed equally among the 8 separate executions of The first cfs_write() takes for CFS_CRYPT_SW and CFS_CRYPT_HW slightly more time than the following three as some time to create the log file structure in flash memory is needed. The 5th write takes considerable more READING OF 2048byte IN 8 BLOCKS OF 256byte.
time than previous writes as the log file of size NL = 4 is full and a merge must be executed before a log record can be written. During merge encryption is performed which the overall system performance.
requires significant processing time. The use of encryption hardware support improves encryption performance by 47%. B. cfs_read() Performance With CFS_CRYPT_HW_M the first 4 write operations are In this second experiment the file created in the previous faster than CFS_APP as data is written to the cache located experiment (2048byte file size) is read using a sequence of cfs_read() calls. With each cfs_read() call, SR bytes When decreasing the write size SW to 64bytes, 32bytes and are read from the file system (SR ∈ {16, 32, 64, 256}). The finally 16bytes the overall time necessary to write the file of execution time of each cfs_read() call is measured. The2048bytes increases (see Figure 2). This is expected as each time necessary for reading the complete file is shown for all cfs_write() call is associated with additional overhead.
For example, the overall time to write a file of 2048bytes Using CFS_APP and SR length increases from 112.7ms to 211.6ms when switching read all 2048byte is 25.1ms. With CFS_MOD this from SW = 256byte to SW = 16byte with CFS_CRYPT_HW. time increases to 30.6ms. With CFS_CRYPT_SW and Note that CFS_CRYPT_HW_M outperforms CFS_MOD for CFS_CRYPT_HW execution times are 693.2ms and 381.1ms;SW = 16byte. This means that under this condition Codo, with CFS_CRYPT_SW_M and CFS_CRYPT_HW_M times which performs caching and encryption, outperforms the stan- are 608.8ms and 295.1ms. Again, the overall time of reading dard CFS when operating on files that have been modified.
2048byte to the file is not distributed equally among the 8 Summary: The Codo CFS is relatively expensive in compar- separate executions of cfs_read() with SR = 256byte ison to CFS. CFS does, however, not provide data confiden- (see Table II). The first cfs_read() of CFS_CRYPT_SW, tiality and this feature cannot be implemented at zero cost. For CFS_CRYPT_HW and CFS_CRYPT_HW_M requires a example, the overall execution time for writing SW = 256byte merge as this first read is performed after the previous exper- increases with Codo CFS (CFS_CRYPT_HW_M) compared to iment in which the file was written and the log file structure CFS (CFS_APP) by a factor of 4. However, individual write was filled. Also the 5th read requires a merge as the log file operations that do not require merging and encryption are is filled. All 8 reads require reading from the flash memory faster with Codo (CFS_CRYPT_HW_M) (by a factor of 1.6 followed by decryption before the decrypted data is placed in for the first write with SW = 256byte). Furthermore, within the log file structure.
an application scenario it might be possible to schedule costly When decreasing the read size SR to 64bytes, 32bytes and merge and encrypt operations at times the system is idle and finally 16bytes the overall time necessary to read the file thus the overhead for providing confidentiality may not impact of 2048bytes increases as shown in Figure 3. However, the times necessary for individual cfs_read() calls have an recorded data.
uneven distribution. For example, for SR = 16byte with includes a merge, decryption of 256byte of data and placement Codo is a novel framework for confidential data storage on of this data in the cache (the log file). The next 15 read sensor nodes. We have described and evaluated a Codo imple- operations require 0.5ms each as the decrypted data is now mentation for Contiki. As described, Codo addresses a number available in the cache. The 16th operation requires 14.8ms as of shortcomings in existing secure storage solutions. Codo a new block of 256byte is decrypted and moved to the cache. matches hardware capabilities with security requirements; in- Summary: Reading a securely stored file requires consid- network processing capabilities are preserved while providing erable more effort than reading the file form the original confidentiality.
CFS. For example, the overall time to read a 2048byte Security requires a processing overhead which is considerable.
file in 256byte blocks with CFS_CRYPT_HW_M increases This processing overhead is proportional to the increase in by a factor of 11.7. However, not every read operation is energy consumption of a node as the CPU is active for equally expensive. For example, when using a read size of longer. However, the CPU is generally the smallest energyS consumer (radio and sensors consume far more energy) and R = 16byte with CFS_CRYPT_HW_M, read operations increase by a factor of 1.3; only when merge and/or decryption the overall increase in energy consumption is reasonable for operations are necessary read operations are much more costly. better security. The exact reduction of node lifetime depends on the particular CPU type and sensor platform.
Instead of using Codo which enables caching of unencrypted data one could use a simple solution This work is partially supported by CONET, the Cooperating (CFS_SIMPLE) which encrypts/decrypts data before calling Objects Network of Excellence.
cfs_write()/cfs_read() of the original Contiki file system. CFS_SIMPLE would only be usable if it is [1] C. Sreenan, J. S. Silva, L. Wolf, R. Eiras, T. Voigt, U. Roedig, ensured that data is accessed in whole blocks that can be V. Vassiliou, and G. Hackenbroich, “Performance control in wireless encrypted/decrypted in full. Hence, CFS_SIMPLE is only sensor networks: the ginseng project - [Global communications news useful to provide a baseline for comparison here but it is not letter],” Communications Magazine, vol. 47, no. 8, Aug. 2009.
[2] N. Bhatnagar and E. L. Miller, “Designing a secure reliable file system for sensor networks,” in Proceedings of the 2007 ACM workshop on Writing 256bytes of data using CFS_SIMPLE_HW takes Storage security and survivability, ser. StorageSS ’07. New York, NY, 11.7ms (9.4ms for hardware supported encryption and 2.3ms [3] W. Ren, Y. Ren, and H. Zhang, “Hybrids: A scheme for secure dis- for writing to flash memory) when writing to a file that has not tributed data storage in wsns,” in Embedded and Ubiquitous Computing, been modified yet and hence the log file structure is not in use.
2008. EUC ’08. IEEE/IFIP International Conference on, vol. 2, dec.
In comparison, CFS_CRYPT_HW_M requires only [4] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - a lightweight and the data is written to the cache in RAM. A performance flexible operating system for tiny networked sensors,” in Local Computer penalty only occurs for writes when the log file structure is full Networks, 2004. 29th Annual IEEE International Conference on, nov.
and a merge has to be performed (see previous paragraphs).
[5] N. Tsiftes, A. Dunkels, H. Zhitao, and T. Voigt, “Enabling large-scale We note a similar performance difference for read storage in sensor networks with the coffee file system,” in Proceedings of operations. CFS_SIMPLE_HW requires 12.5ms while the 2009 International Conference on Information Processing in Sensor [6] R. Di Pietro, D. Ma, C. Soriente, and G. Tsudik, “Posh: Proactive The performance difference between CFS_SIMPLE_HW co-operative self-healing in unattended wireless sensor networks,” in and CFS_CRYPT_HW_M diminishes when handling smaller Reliable Distributed Systems, 2008. SRDS ’08. IEEE Symposium on, amounts of data in each read and write operation. This is due to [7] J. Girao, D. Westhoff, E. Mykletun, and T. Araki, “Tinypeds: Tiny persis- the fact that then encryption/decryption times are comparable tent encrypted data storage in asynchronous wireless sensor networks,” to times necessary for flash read/write operations. For example, Ad Hoc Netw., vol. 5, pp. 1073–1089, September 2007.
[8] “Ironkey.” [Online]. Available: https://www.ironkey.com/ when writing 16bytes CFS_SIMPLE_HW requires 1.2ms [9] P. Szczechowiak, L. B. Oliveira, M. Scott, M. Collier, and R. Dahab, “Nanoecc: testing the limits of elliptic curve cryptography in sensor Summary: The caching functionality provides a performance networks,” in Proceedings of the 5th European conference on Wireless sensor networks, ser. EWSN’08, 2008, pp. 305–320.
benefit for individual read and write operations. Sensor net- [10] W. Hu, P. Corke, W. C. Shih, and L. Overs, “secfleck: A public key work applications that access files sequentially (e.g. writing a technology platform for wireless sensor networks,” in Proceedings of continuous log file) may benefit from the increased read/write the 6th European Conference on Wireless Sensor Networks, ser. EWSN speed. However, applications that benefit most from the cache [11] C. Kaufman, P. Hoffman, Y. Nir, and P. Eronen, “Internet Key Exchange functionality are applications that access the same data in Protocol Version 2 (IKEv2),” RFC 5996, Internet Engineering Task a file multiple times. For example, some applications may record sensor data and then perform periodically complex data processing which requires multiple reads of the previously http://certivox.jira.com/wiki/display/MIRACLPUBLIC/Home

Source: http://www.shahidraza.info/pdf/codo.pdf