Home

D6.2.1: Platform validation and verification

Contents

1. D6 2 1 RE IT a COMPOSITION COMPOSITION Semantic DB DISCOVERY Service Discovery Engine TECHNOLOGY Query Filter INDEPENDENT Preprocessor Engine ee a o m e i Discovery Discovery Discovery Regist b Ld Protocol 1 Protocol 2 Protocol N Figure 5 4 Details of the Discovery core SPD service Where the following functional elements can be identified Discovery Engine it is a technology independent functionality in charge to handle the queries to search for available pSHIELD components sent by the Composition service Query Pre processor it is a technology independent functionality in charge to enrich the query sent by the Composition service with semantic information related to the peculiar context Filter Engine it is a technology independent functionality in charge to semantically match the query with the descriptions of the discovered SPD components Discovery Protocol it is a technology dependent component in charge to discover all the available SPD components description stored in the Service Registry using a specific protocol e g Service Location Protocol SLP or Universal Plug and Play Simple Service Discovery Protocol UPnP SSDP etc The discovery functionality is thus composed by a technology independent core to manage the discovery of available SPD functionalities independently from the specific discovery protocol and technology and some adapte
2. 27 5 3 Heterogeneous Wireless Sensors Networks and secure COmmubieallOl ara 29 5 3 1 General Functionality i 29 5 3 2 WSN Cryptography levels description 29 5 3 3 WSN key BXOIAIt B associe rentas do Riu thai tec manes EU deiude 29 5 3 4 Communication mechanism essere 31 Platform verification process eere 36 6 1 Tests identification and description 36 6 1 1 Test identification c 36 Page iii SEVEN FRAMEWORK PROGRAMME 6 1 2 Testbed definition i 37 6 1 3 Testbed devices initialization cccccsccccecessssssseceeecssssesseeeeeeeessesses 39 6 2 TESIS er rc rrr 41 6 2 1 AUdIPTeSIS ERREUR CREME IEEE 41 6 2 2 CS Cryptographic SUpport i ie 47 6 2 3 Identification and authentication testS n 58 6 2 4 Protection of the SPD functionalities tests 61 6 2 5 SPD Functions Management Tests sse 63 6 3 Completeness of teStS ccccsssssececsssscecesssseeceessssseeeesessseeeesess 66 7 Conclusions eere ee eene eene neenon see sons sessssssessssseessssses OF Page iv Issue 1 SEVEN FRAMEWORK E 5 PROGRAMME Fig re T Platoni Structure lie 13 Figure 4 2 Central Unit representation ii 13 Figure 4 3 Real t
3. RE D6 2 1 C Wire less receive encrypted message Sensor Node I message SYNC_ START_MSG send SYNC_ACK_MSG SensorNodePubKey message LEVEL SET_MSG wrong CRC decryptMessage level encrypted message check CRC computeCRC decryptMessage old_level encrypted message check CRC computeCRC storePowerNodePublicKey setLevel 0 setMode MODE WAITING LEVEL right CRC send LEVEL ACK encrypted previous level setLevel message level setMode MODE OPERATIONAL decryptMessage level encrypted message check CRC computeCRC right CRC send MEASURES encripted message Figure 5 13 Sensor node behaviour From Power Node requests RE Page 35 of 68 p SHIELD D6 2 1 RE 6 Platform verification process Test documentation provides all information useful to repeat tests to ensure that they work as described and that documented results are obtained Tests described below clearly identify the purpose of each test so that it s possible to identify the objective It should also identify the related SPD function for each test this will assist in meeting the traceability requirements 6 1 Tests identification and description The proposed test plan has the purpose to demonstrate that all SPD functions implemented in the pSHIELD for the specific scenario work properly without errors T
4. e Microsoft Windows XP Operating System certified configuration 9 2 TelosB sensors In order to set the devices operating after connect them by USB to a computer Linux Operating system next commands must be executed e See the list of connected motes motelist e Change permissions of each device x connection like chmod 666 dev ttyUSBx e On code directory install code in mote that will play the role of power node make f Makefile GW telosb install e On code directory install code in each mote x existing in motelist that will play the role of sensor nodes make f Makefile Node telosb install x bsl dev ttyUSBx Image bellow show a example of last lines of output in terminal after the command make f Makefile GW Telosb install MSP430 Bootstrap Loader Version 1 39 telos 8 Mass Erase Transmit default password Invoking BSL Transmit default password Current bootstrap loader version 1 61 Device ID f16c Changing baudrate to 38400 Program 40374 bytes programmed Reset device rm f build telosb main exe out build telosb main ihex out Sensor nodes after being flashed will turn on the blue LED waiting synchronization with power node During this initialization phase some errors can occur e ntask 2 if the nodes aren t well connected and recognized by computer it will appear the below message pshieldgpshield cvs pshield wsn2 sudo chmod 666 dev ttyUSBO chmod
5. 250 kbps data rate elntegrated on board antenna e8MHz TI MSP430 microcontroller with 10kB RAM eLow current consumption e1MB external flash for data logging Programming and data collection via USB eSensor suite including integrated light temperature and humidity sensor RE Page 15 of 68 p SHIELD D6 2 1 RE The Crossbow TelosB can be powered by two AA batteries If is plugged into the USB port for programming or communication power is provided from the host computer and If is always attached to the USB port no battery pack is needed 3 Configuration Manuals these are the manuals provided by HW and SW producers in particular to the aim of verification the following manuals were considered e Windows XP Professional with SP2 Evaluated Configuration User s Guide version 3 0 July 11 2007 e MOTE IV Telos revB Low Power Wireless Sensor Module Manual e CROSSBOW TPR2400 2420 Quick Start Guide Rev A May 2005 Doc 7430 0380 01 4 3 SPD functionalities definition SPD functionalities used on hypothesized pSHIELD scenario platform are based on D2 2 1 concepts The platform performs SPD functions belonging to the following classes 1 AU SPD Audit 2 CS Cryptographic Support 3 IA Identification and Authentication 4 PT Protection of the SPD functionalities 5 SM Security Management 4 3 1 Class AU SPD Audit SPD audit involves recognizing recording storing and analyzing informati
6. 3 To add a Logon Right or Privilege to an account click the Add button and browse the appropriate account directory for the desired account RE Issue 1 Page 65 of 68 p SHIELD D6 2 1 RE 6 3 Completeness of tests In the following table it is demonstrated how tests set defined in paragraph 6 2 is complete to verify pSHIELD platform SPD functionalities Table rows contain SPD functionalities and columns contain tests SPD functionalities and tests are grouped by classes AU CS IA PT SM ri NTO TP OL IN M s LO TKR IDO rr OQ Ol Q rc IN E E E E R R e le le le E Fe le JF lelelelelele Class Comp GEN 1 X X X X X AU GEN 2 XJ XJ X X X SAR 1_ X X X X X SAR 3 XXX X CKM 1 X X X X X X X X CS CKM 2 X IX X X X X XX COP 1 XIX XIXIX XIXIX IA UID 1 XXX UAU 1 X X X PT STM 1 XIX MTD 1 X SM SMR 1 X X SMF 1 X X Table 6 1 Cross reference verification RE Page 66 of 68 Issue 1 p SHIELD D6 2 1 RE 7 Conclusions The purpose of the pSHIELD project has been to put the basis of SPD composability in Embedded System domain and to demonstrate it by means of a reduced but significant scenario At first a series of innovative concepts and technologies has been developed in technical WPs WP3 4 5 and then a subset of these results has been selected for further integration in a co
7. SEVEN FRAMEWORK PROGRAMME Project no 100204 p SHIELD pilot embedded Systems architecture for multi Layer Dependable solutions Instrument type Capability Project Priority name Embedded Systems including RAILWAYS D6 2 1 Platform validation and verification Due date of deliverable M18 Actual submission date M17 Start date of project 1 June 2010 Duration 19 months Organisation name of lead contractor for this deliverable pSHIELD Consortium Revision Issue 1 Project co funded by the European Commission within the Seventh Framework Programme 2007 2012 Dissemination Level PU Public PP Restricted to other programme participants including the Commission RE Restricted to a group specified by the consortium including the Commission X CO Confidential only for members of the consortium including the Commission Services SEVEN FRAMEWORK PROGRAMME Document Authors and Approvals Name Company Andrea Morgagni Selex Elsag Renato Baldelli Selex Elsag Universit degli studi Andrea Fiaschetti di Roma La Sapienza Universit degli studi Vincenzo Suraci di Roma La Sapienza Sergio Wanderlingh Tecnologie nelle Reti e nei Sistemi de Oliveira Critical Software Reviewed by Name Company Approved by Nme Company Pedro Miguel Rendeiro T Modification History Page ii Issue 1 A GQ N a Issue 1 SEVEN FRA
8. Professional SP 2 CC EAL 4 augmented with ALC FLR 3 certificated In particular to implement Security Management on pSHIELD the following families and components has been identified 1 SM MTD Management of SPD functionalities data with the following components SM MTD 1 Management of SPD functionalities data e SM MTD 1 1 The SPD functionalities shall restrict the ability to modify the minimum password length password complexity policy to pSHIELD platform administrator 2 SM_SMR Security Roles with the following components SM SMR 1 Security management roles RE Page 19 of 68 p SHIELD D6 2 1 RE SM SMR 1 1 The SPD functionalities shall maintain the roles pSHIELD platform administrator and operator SM SMR 1 2 The SPD functionalities shall be able to associate users with roles 3 SM_SMF Specification of Management Functions with the following components SM SMF 1 Specification of Management Functions SM SMF 1 1 The SPD functionalities shall be capable of performing the following security management functions a modify access control attributes associated with an object enable disable modify the behaviour of the audit function clear the audit trail modify the set of events to be audited read the audited events initialize and modify user security attributes modify the minimum allowable password length modify the password complexity restriction modify the unsuccessful authenticatio
9. cannot access dev ttyUSBO No such file or directory e n task 2 if the nodes aren t well connected and recognized by computer but the command it s executed without super user permissions the following output will appear RE Issue 1 Page 39 of 68 p SHIELD D6 2 1 RE chmod changing permissions of dev ttyUSBO Operation not permitted pshieldgpshield cvs pshield wsn2 chmod 666 dev ttyUSBO e n task 3 and 4 if the nodes aren t well connected recognized by computer and the user haven t the right permissions see task 2 the last lines of output will by similar to these ones cp build telosb main ihex build telosb main ihex out found no motes using bsl auto 3 HP Laptop e SmartRF packet sniffer application configuration 10 e CC2530 DK board configuration 11 RE Page 40 of 68 Issue 1 p SHIELD D6 2 1 RE 6 2 Tests 6 2 1 Audit tests AU T01 Purpose Reading of information from the audit records Initialization Windows events and Performance Logs and Alerts are recorded phase by the Event Log service The Event Log service starts automatically when Windows XP Professional is started All users can view the Application and System logs however only administrators have access to the Security logs Positive test Expected The Event Viewer Security log displays the following types of events result Success audit An audited security access attempt that succeeds For examp
10. sudo emulator avd android amp 5 On android pSHIELD application set the computer running knopflerfish container IP and choice one SPD level pressing one of the stars in example level 1 was chosen Output 1 After first procedure the TinyOS 2 x Serial Forwarder GUI opens and make automatically the synchronizing with Power Mote if it is correctly connected to the machined and it has the correctly permissions RE Issue 1 Page 47 of 68 p SHIELD RE D6 2 1 TinyOS 2 x Serial Forwarder Listening to serial amp dev ttyUSBO telosb Listening for client connections on port 9002 serial amp dev ttyUSBO 115200 resynchronising 9002 erver Port Mote Communications serial dev ttyUSBO telosb Verbose Mode Pckts Read 14 Pckts Wrttn 15 Num Clients 1 File Edit Bundles View Help o pim l Stant levet o conugpatgorithm IMPL SecurityAgent INPL Sema X aS E E Ns Na Bal z I 1 Xy Sy E main vien to view detail information System Bundle LogService cm Console Declarative Se Event Admin I Level 9 I ln Ns L7 Na Na J kn prefs util LIB JSDK AP bundlereposit Device Manager UserAdmin te a tt ti tt M 6 KO Di My HTTP Server FW Command LogCommand CM Command HTTP root IMPLTTY Console PB v v 6 Ed 4 Telnet Consol httpconsole L Remote
11. 12 Sensor node behaviour represented as a states machine The behaviour of a Sensor Node when receiving a message from wireless network it s depicted in the Figure 5 13 The message received can be unencrypted or encrypted If it is unencrypted and it is a sync start message sensor node will store the Power node public s key set level to 0 change the state to waiting level and send back an acknowledge message with its Public key Otherwise when Sensor Node receives a level set message while being in waiting state the first step is to decrypt it and after that it checks its CRC If there is a bad CRC match probably it s because the level set message it s repeated Sensor Node already changed its level but it continues receiving messages asking for the level change so it has to be checked if the message can be decrypted with the last Sensor Node encrypt level If CRC check fails again the message is discarded If CRC check was successful Sensor Node updates its current level and state and sends back an encrypted acknowledge message When Sensor Node is in operational state and receives a measure request message decrypts it and checks its CRC If CRC check fails the message is discarded If CRC check was successful Sensor Node reads data from its three different sensors creates a message with that information computes CRC message encrypts it and sends it by wireless to the Power node RE Page 34 of 68 Issue 1 p SHIELD
12. 23 2010 Page 68 of 68 RE Issue 1
13. all nodes are synchronized I I Sensor Node 1 4 SyncStartMsg dest 1 4 SyncAckMsg source 1 4 SyncAckMsg source 1 4 loop changing encryption level I I while here are remaining attempts 3 AND until all nodes changeg level N Encryption level 2 I uu LevelAckMsg dest 1 4 level 3 l e LevelSetMsg dest 1 4 level 3 ua LevelAckMsg source 1 4 LevelAckMsg source 1 4 lt LevelChangeMsg level 3 loop receiving values from sensors while B nsorMote have battery AND while MeasureMsg listener is registered MeasureReqMsg dest 1 4 MeasureReqMsg dest 1 4 N MeasureMsg source 1 4 temperature humidity light lt N Su x lt 4 MeasureMsg source 1 4 temperature humidity light IN Encryption level 3 Figure 5 9 Example of messages exchanged between Power and Sensor nodes There are also three types of communications scopes e Synchronizing When pSHIELD system starts the synchronism between Power Node and the various Sensor Nodes is performed OSGI sends one start message for each existent sensor node to Power Node which will forward the same message for its destination After each Sensor Node receiving this start message they will send back an acknowledge message to Power Node and this one will forward the message to OSGI From now on there are synchronism between the nodes and ca
14. connected it will receive the public key and stores in the memory The sensor node will also perform the same procedure When it boots it will create the private key and then send the public key to the network The Power Node will also receive the public keys from sensor nodes and store them in the memory The Power node and all the nodes will use the generated private and public keys to secure the communication After exchange of the public keys by radio the nodes will send and receive encrypted messages The ECIES scheme grants the confidentiality due to encryption and non repudiation Telosb Node Telosb Power node i H Init Init 1 ni Generate Generate PrivateKey PrivateKey Generate and send PublicKey PubKeyMsg save Publicke Send Save PublicKey 2 PubKeyMsg PublicKey send Message PacketMsa Decrypt Message Figure 5 8 Exchange public keys protocol between Power and Sensor Node RE Page 30 of 68 Issue 1 p SHIELD RE D6 2 1 5 3 4 Communication mechanism In the wireless sensor network the communication mechanism has three main types of entities that communicate with each other OSGI Power Node and Sensor Nodes Through the diagram in Figure 5 9 it is possible to see an example of messages exchanged between them OSGI I loop synchronizing l SyncStartMsg dest 1 4 Power Node l while there are remaining attempts 3 AND until
15. important The default expiration date is 42 days however it can be set to any value from 0 to 999 e Minimum Password Age The Minimum password age setting determines how long users must keep a password before they can change it This field can be set to prevent users from cheating the password system by entering a new password and then changing it right back to the old one By default Windows XP Professional lets users change their passwords immediately e Minimum Password Length The Minimum password length setting establishes the minimum number of characters required for a password If it hasn t been changed already the default setting should be changed immediately The default is to allow empty passwords passwords with zero characters which is definitely not a good idea e Passwords Must Meet Complexity Requirements Beyond the basic password and account policies Windows XP Professional includes facilities for creating additional password controls The functions implemented by enabling the Passwords must meet complexity requirements setting in Password Policy are enforced when a user or administrator attempts to change the password for a user account For example in Windows XP Professional the strong password filter requires that passwords not contain all or part of the user s account name not be less than six characters in length and contain characters from at least three 3 of the following four 4 classes 1 Englis
16. semantic models e g metrics and descriptions and interfaces necessary to perform the SPD composability The objective of the platform verification activity is to verify the platform behavior with respect to the selected scenario by means of focused functional tests RE Issue 1 Page 9 of 68 p SHIELD D6 2 1 RE 3 Terms and Definitions Involves recognizing recording storing and analyzing information Audit related to SPD relevant activities The resulting audit records can be examined to determine which SPD relevant activities took place Authorised A user who possesses the rights and or privileges necessary to User perform an operation The CC has organised the components into hierarchical structures Classes consisting of Families consisting of components This Class and SR j Famil organisation into a hierarchy of class family component element y is provided to assist consumers developers and evaluators in locating specific components The Common Criteria for Information Technology Security Evaluation abbreviated as Common Criteria or CC is an international standard ISO IEC 15408 for computer security certification It is currently in version 3 1 Common Criteria is a framework in which computer Common system users can specify their security functional and assurance Criteria requirements vendors can then implement and or make claims about the security attributes of their products a
17. using the correct case Output Logon success permit to an authorised user to access SPD functionalities mediated action on behalf of the user itself RE Issue 1 Page 59 of 68 p SHIELD D6 2 1 RE IA TO3 Purpose Demonstrate that a disabled user cannot access to SPD functionalities mediated action on behalf of the user itself Initialization Process of user disabling phase Negative test Expected An identification and authentication process do not permit a disabled result user to access SPD functionalities mediated action on behalf of the user itself Input data Data to fill in the logon window Procedure Initiate a trusted path for login by pressing CTRL ALT DELETE If the administrator has implemented a log on banner a message banner will appear on the screen Read the message and click OK or hit Enter to continue with the logon process At the Log On to Windows interface enter a user name and password for a disabled user Click on the Options gt gt button In the Log on to drop down box select to either log on to the local computer Click OK It appear a logon message with the following contents The system could not logon you Make sure your User name and domain are correct then type your password again Letter in passwords must be typed using the correct case Output Logon process do not permit to a disabled user to access SPD functionalities mediate
18. 2 Click Start point to All Programs point to Administrative Tools and select Computer Management 3 In the console tree expand Event Viewer Right click Security or other event log point to View and select Find Output The Find in local Security interface will appear Under Event types specify the types of events to search for In Event source Category Event ID User Computer or Description specify additional information as needed to further define the search Click the Find Next button This will find and highlight the first event matching the search criteria Clicking the Find Next button again will find the next matching event This can be done continuously to search through the entire log for each matching event RE Issue 1 Page 43 of 68 p SHIELD D6 2 1 RE AU T03 Purpose Demonstrate that security relevant event has been recorded Initialization Execute test IA T01 phase Positive test Expected The security relevant event generated during initialization phase is result recorded in the audit file and the Event Viewer Security log displays it Input data Path to follow and data to fill in the proper fields Procedure Follow the procedure of test AU TO1 to reach the Event Viewer console and the procedure of test AU TO2 to select Logon Logoff event category Output Successful logon visible in Properties window number Event 528 and Type Date Time Source Category User Compute
19. CAL_MACHINE SYSTEM CurrentControlSet Services W32Time Config In the right panel right click AnnounceFlags and then click Modify In the Edit DWORD Value dialog box under Value data verify that value is 5 and then click OK 3 Locate and then click the following registry subkey HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services W32Time TimePr oviders NtpClient Issue 1 RE Page 61 of 68 p SHIELD D6 2 1 RE In the right panel right click SpecialPolllnterval and then click Modify In the Edit DWORD Value dialog box under Value data verify that value is TimelnSeconds and then click OK 4 Locate and then click the following registry subkey HKEY LOCAL_MACHINE SYSTEM CurrentControlSet Services W32Time TimePr oviders NtpServer In the right pane right click Enabled and then click Modify In the Edit DWORD Value dialog box under Value data verify that data is 1 and then click OK 5 Locate and then click the following registry subkey HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services W32Time Parame ters In the right panel right click NtpServer and then click Modify In Edit Value verify that data is 192 168 1 7 mobile terminal IP address and then click OK 6 Locate and then click the following registry subkey HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services W32Time Config In the right panel right click MaxPosPhaseCorrection and then click Modify In the E
20. ECIES Initialization Execute the test CS T01 phase Positive test Expected Verify on packet sniffer application interface the exchange of result messages between Power node and all Sensor Nodes is incomprehensible without decryption when level of encryption is 2 AES 256 and 3 ECC ECIES Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 3 5 stars Procedure With pSHIELD android application change SPD level from the current level to level 2 3 stars to test AES 256 encryption Change SPD level from the current level to level 3 5 stars to test ECC ECIES encryption Output Encrypted messages collected by packet sniffer For level 2 AES 256 each message will have 2 32 bytes of length 32 bytes 256 bits For level 3 ECC ECCIES there aren t a specific message size Page 54 of 68 RE Issue 1 p SHIELD D6 2 1 RE CS T06 Purpose Verify that data acquired by one Sensor Node are correctly transmitted to OSGI platform Initialization Execute the test CS T01 phase Positive test Expected Receive on OSGI platform GUI windows the sensor measures with result real values sent over WSN Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 1 stars Procedure Wait for data Output GUI window from OSGI pSHIELD platform showing measures given by Sen
21. FW API Desktop DiscoveryEngi DiscoveryProt x Bundle Repository Manifest Closure Services Packages Log Events Prefs J Staoury Service wameaccountTng stdout Service NameAccounting stderr java net Connecttxception Connection refused stderr at java net PlainSocketTmp1 socketConnect Native Method stderr at java net PlainSocketInp doConnect PlainSocketInp java 351 stderr at java net PlainSocketImp connectToAddress P ainSocketImp java 213 stderr at java net PlainSocketInp connect PlainSocketInp1 java 200 stderr at java net SocksSocketInp connect SocksSocketInp1 java 366 stderr at java net Socket connect Socket java 529 stderr at java net Socket connect Socket java 478 stderr at java net Socket init Socket java 375 stderr at java net Socket init Socket java 189 stderr at eu artenis shield overlay controlalgorithn inp ControlAlgorithmC1ient run ControlAlgori thmC1ient java 40 2 b z 3 After fifth task Page 48 of 68 RE Issue 1 p SHIELD D6 2 1 RE pSHIELD Security Agent Viewer Configuration Desired SPD level Current SPD level gt It s a Site Local address OKAY IPv4 10 0 2 15 PORT 6000 4 Messages caught by packet sniffer regarding to the synchronization protocol P nbr Time ms Dest aa 0 Adde
22. MEWORK PROGRAMME Contents Executive summary sssssssesssooesssssooessssseosssssseoeesssseoessssseesesssse 8 Introduction adire 9 Terms and Definitions 10 pSHIELD Scenario Platform 12 4 1 Introduction ici 12 4 2 Platform definition t 12 4 3 SPD functionalities definition eee 16 4 3 1 Class AU SPD Audit erret nennen etos 16 4 3 2 CS Cryptographic Support sees 17 4 3 3 Class IA Identification and authentication 18 4 3 4 Class PT Protection of the SPD functionalities 19 4 3 5 Class SM SPD functions Management 19 Platform validation process rrrrrrrrereririneozinie 21 5 1 PSHIELD Ontology occ 21 5 1 1 Validation against model representation 21 5 1 2 Validation against SPD Composition esses 22 5 2 Middleware and Overlay for discovery and composition 24 5 2 1 Validation against GISGOVBLIV ucuis corset tonno tain Sr ons patid ta pido 24 5 2 2 Validation against composition ees 26 5 2 3 Validation against Orchestration sss 26 5 2 4 Validation against the SPD level change
23. NTP client to synch its clock with the GSM network Indeed the NTPD NTP server daemon running in the mobile device is synched with the Network Operator base station clock through the NITZ Network Identity and Time Zone protocol 1 Source NTP Server installation guide for linux based systems link Page 14 of 68 RE Issue 1 p SHIELD D6 2 1 RE Issue 1 The mobile terminal is a HTC Desire S equipped with a ARMv7 1Ghz processor and 768 Mbyte RAM It has been used to be at the same time the clock synch as well as the Central Unit Graphic User Interface GUI Wireless Sensor Network WSN it is composed by Crossbow TelosB devices These devices are sensor nodes and the PAN coordinator it is the bridge between the wireless sensor network and the framework in the central unit it is called Power Node too Topology Network that is implemented by Crossbow TelosB devices can be only Star topology Each communication will be directly from the PAN coordinator node to the sensor node and vice versa Sensors RT transceiver Figure 4 4 Crossbow TelosB node In detail Crossbow TelosB node is an open source platform with the USB programming capability an IEEE 802 15 4 radio with integrated antenna a low power MCU with extended memory and an sensor suite Crossbow s TelosB hardware platform features includes eIEEE 802 15 4 ZigBee compliant RF transceiver 2 4 to 2 4835 GHz a globally compatible ISM band
24. PD functionalities shall be able to associate each auditable event with the identity of the user that caused the event 2 AU SAR Security audit review with the following components AU SAR 1 Audit review e AU SAR 1 1 The SPD functionalities shall provide authorised users with the capability to read a list of audit information from the audit records e AU SAR 1 2 The SPD functionalities shall provide the audit records in a manner suitable for the user to interpret the information AU SAR 3 Selectable audit review e AU SAR 3 1 The SPD functionalities shall provide the ability to apply a method of selection and or ordering of audit data based on criteria with logical relations 4 3 2 CS Cryptographic Support This class is used to implement cryptographic functions the implementation of which could be in hardware firmware and or software The identified SPD functionalities of these families are implemented in the Crossbow TelosB devices In particular to implement cryptographic support on pSHIELD the following families and components has been identified 1 CS CKM Cryptographic key management with the following components CS CKM 1 Cryptographic key generation e CS CKM 1 1 The Power Node and each single Sensor Node generates cryptographic keys for different levels of encryption A random key generation with key size 128 256 when AES is used A public private key generation using an algorithms that create a unique key
25. VEL Ack Msg from 1 Level 3 Node 1 changed his encryptation to level 3 Level 3 Received Measure from 1 32 88999999999999 humi FE 29 858000000000004 Level 3 Receved Measure from 1 temperature 32 970000000000006 AUT 29 939 A GUI windows from OSGI pSHIELD platform showing measures given by Sensor nodes for one of each level through special GUI windows for each of the three levels G Rare E N Clear Log Hide Me N Clear Log Hide Me Clear Log Hide Me r Details from above images Level 1 Received Measure from il temperature 32 68 humidity 30 101 light 31 0 Level 2 Received Measure from 1 temperature 32 85 humidity 30 1415 light 29 0 Level 3 Received Measure from 1 temperature 32 970000000000006 humidity 29 939 light 30 0 I I I I t 1 I I I L I LI L L I I 1 L I L As it can be seen for different levels of encryption besides the measures should be correctly sent and decrypted by Power Node Page 56 of 68 RE Issue 1 p SHIELD D6 2 1 RE CS T08 Purpose Reliability of Sensor communication Initialization Execute the test CS T07 phase Positive test Expected Receive on OSGI platform GUI win
26. arted Level 1 SIS EDD for the following Level 1 Level 1 Level 1 evel Nodi Level 1 Receh temperatu temperature 32 74 humid 3 30 020000000000003 gt Serdi ino iva a ma B p Received LEVEL Ack M e 1 changed his CARRI to Ga 1 ived Measure from 1 re iB 669999999999995 29 372 temperature humidity 29 21 Qu umidity 29 291000000000004 33 0 ight level 2 Received Measure from 1 temperature 33 169999999999995 humidity 29 21 light 32 0 Level 2 Received Measure from 1 temperature 33 0 humidity light 2 light 31 0 Level 1 Rei ER ene Measure from 1 Level 2 Received Measure from 1 temperature 32 68 Tam et 33 13999999999999 humidity 30 101 29 453000000000003 light 31 0 li ht 30 0 Level 1 Received Measure from 1 Level 2 Received Mesai from 1 light 3 light inva 1 Receh ived Measure from 1 Level 2 Received Measure from 1 mperature 32 temperature 32 8 hare 30 262999999999998 humi no 30 ins light 30 0 light 29 Level 3 light 30 0 light 3 light Level 3 Bundle started Level 3 Changi ng encryption for the following light 30 0 Level 3 Received Measure from 1 temperature 32 73 humidity 30 3035 PSHIELD PowerNode Information gt Sen i i va 3 msg to 1 Received LE
27. d action on behalf of the user itself RE Page 60 of 68 Issue 1 p SHIELD D6 2 1 RE 6 2 4 Protection of the SPD functionalities tests PT T01 Purpose Verify that pSHIELD platform receive a reliable timestamp by an authorative external time source Initialization No initialization phase phase Positive test Expected result pSHIELD Audit Events associated Timestamp is reliable T Input data No input data Procedu re The Windows Time service W32Time is designed to maintain date and time synchronization for computers running Windows 2000XP 2003 W32Time is based on the Simple Network Time Protocol SNTP as specified in RFC RFC 1769 now superceded by RFC 2030 As described in par 4 2 pSHIELD Central Unit have its own clock controlled By synching to a Bluetooth connected external GSM device that is an authorative source Test verification is realized checking the configuration indicated in the following steps On the Windows XP desktop click Start click Run type regedit and then click OK 1 Locate and then click the following registry subkey HKEY LOCAL _MACHINE SYSTEM CurrentControlSet Services W32Time Parame ters In the right panel right click Type and then click Modify In the Edit Value dialog box under Value data verify that value is NTP and then click OK 2 Locate and then click the following registry subkey HKEY LO
28. d in literature Thus all the three validation criteria are satisfactory matched http www openslp org doc security threat analysis min security html and http www bettstetter com publications vettorello 2001 wadhoc slp pdf http www ifi uzh ch pax uploads pdf publication 1099 Bachelorarbeit pdf RE Page 26 of 68 Issue 1 p SHIELD D6 2 1 RE The objective of the Middleware and Overlay platform verification activity is to check the platform behavior with respect to the selected scenario by means of focused functional tests 5 2 4 Validation against the SPD level change Two different type of approach have been taken to validate the Middleware and Overlay platform against the SPD level change The first approach is on a theoretical basis the second is bases on concrete field tests From a theoretical point of view the joint operation of the pShield overlay the pShield Core SPD services discovery composition and orchestration and the pShield middleware layer that interact with the network and the node layer too apply as a closed loop system where the Current SPD level measured by the pShield middleware is continuously compared with the Desired SPD Level by the Overlay The Overlay applies for configuration rule to react against any potential SPD gap between the desired level and the current level The configuration rules are then enforced into the system of embedded systems by the Core SPD services and applied concre
29. dit DWORD Value dialog box click Decimal under Base In the Edit DWORD Value verify that data is 54000 and then click OK 7 Locate and then click the following registry subkey HKEY LOCAL_MACHINE SYSTEM CurrentControlSet Services W32Time Config In the right pane right click MaxNegPhaseCorrection and then click Modify In the Edit DWORD Value dialog box click Decimal under Base In the Edit DWORD Value verify that data is 54000 and then click OK Output The regedit configuration of the Central Unit Operating System is correct RE Page 62 of 68 Issue 1 p SHIELD D6 2 1 RE 6 2 5 SPD Functions Management Tests SM TO1 Purpose Demonstrate the possibility for the authorized administrators to manage a users passwords policy which determines settings for password such as enforcement and lifetimes Initialization N A phase Positive test Expected The security provided by a password system depends on the result passwords being kept secret at all times Thus a password is vulnerable to compromise whenever it is used stored or even known In a password based authentication mechanism implemented on a System passwords are vulnerable to compromise at several essential stages related to password assignment distributions management and use For this reason itis expected that the system is able to enforce e password history e maximum password age e minimum password a
30. dows the sensors measures real result values sent over WSN showing similar values independent of level Input data Only the environment data should change Procedure The system should run for one hour without a break Output The output should be similar from the test CS T07 and the devices should communicate without major interruption for one hour RE Issue 1 Page 57 of 68 p SHIELD D6 2 1 RE 6 2 3 Identification and authentication tests IA TO1 Purpose Demonstrate that no SPD functionalities mediated action on behalf of a user can be performed before user is identificated and authenticated Initialization No initialization phase phase Positive test Expected A correct identification and authentication process permit a user to result access SPD functionalities mediated action on behalf of the user itself Input data Data to fill in the logon window Procedure Initiate a trusted path for login by pressing CTRL ALT DELETE If the administrator has implemented a log on banner a message banner will appear on the screen Read the message and click OK or hit Enter to continue with the logon process At the Log On to Windows interface enter a user name and password for an authorised user Click on the Options gt gt button In the Log on to drop down box select to either log on to the local computer Click OK A Windows XP user session start and the user can access SPD functiona
31. enario platform WSN that is the lone part of the system containing selectable SPD functionalities the following functionalities have been considered e d5 SPD measures of identification and authentication WSN e d6 SPD measures of cryptographic support WSN The WSN SPD level computed according to the defined algebra is MIN ds de The reasoner is able to compute configurations thanks to the relations defined in the semantic model he can recognize elements and attributes for example it understands that uTESLA and ECDSA have a different computing contribution to SPD level or that at least one istance for each entities should be present Then through simple algebra rules it can associate to the configuration the corresponding SPD level For validation purposes in the following table all the computable configurations generated by the reasoner are listed with the corresponding SPD level values defined in par 5 2 4 are considered in the reasoned for computing RE Page 23 of 68 p SHIELD D6 2 1 RE OVERALL SPD Foa Eos Me Cryptography 1 uTESLA AES 128 1 uTESLA AES 256 1 uTESLA ECC ECIES 1 ECDSA AES 128 3 ECDSA AES 256 6 ECDSA ECC ECIES Table 5 1 Computable configurations generated by the reasoner Given this list we can confirm by inspection that the reasoner is able to find at least one valid configuration in case it exists or to inform the user about the abse
32. ests are executed with the aim to demonstrate the correct SPD functions implementation Tests can be indicated as positive or negative Positive tests have been designed with the purpose to show the correct functioning modifying input parameters coupled with e nominal values with any accepted intermediates value e smallest accepted values the smallest value for ordinal or cardinal number the smallest string length e biggest accepted values the biggest value for ordinal or cardinal number the biggest string length e borderline values value immediately bigger than the smallest accepted value and value immediately smaller than the biggest accepted value e values only for mandatory arguments minimum input e values all arguments maximum input Negative tests have been designed in order to verify the correct control over input trying e incorrect values e values with different type respect to those expected e borderline values value immediately smaller than the smallest accepted value and value immediately bigger than the biggest accepted value 6 1 1 Test identification Each test is labeled following this scheme RE Page 36 of 68 Issue 1 p SHIELD D6 2 1 RE IF TX where IF is SPD function class identification T stands for Test and X is an identification number e g ID TO2 indicates test number 2 for identification function moreover for each test positive or negative typolog
33. etric key algorithm meaning the same key is used for both encrypting and decrypting the data As said before on subsection Errore L origine riferimento non e stata trovata it is used two different sizes of cryptographic keys for level one is used 128 bits and for level two is used 256 bits Level 3 ECC ECIES The Level 3 uses ECC with the ECIES scheme from TinyECC library TinyECC is a software package providing ECC based PKC operations that can be flexibly configured and integrated into sensor network applications It is used to provide a public key encryption scheme ECIES to the demonstrator 5 3 3 WSN key exchange Issue 1 From the WSN point of view there is one level of key exchange Since the main objective of this prototype was to demonstrate SPD composability mechanism there were not implemented specific key management mechanisms that guarantee the nodes authenticity This task can be accomplished by the implementation of key pre distribution mechanisms as described in D4 2 SPD Network Technologies Prototype Report There are a maximum number of Sensor Nodes that can be connected in WSN For demonstration purpose this number is four 4 RE Page 29 of 68 p SHIELD D6 2 1 RE The scheme implemented in this demonstrator is depicted in Figure 5 8 The Power Node initializes the protocol by generating the private and the public key After generation is concluded it sends the public key trough radio If a sensor node is
34. from a random vector implemented by TinyECC library when ECC is used RE Issue 1 Page 17 of 68 p SHIELD D6 2 1 RE CS_CKM 2 Cryptographic key distribution CS_CKM 2 1 The WSN sensors shall distribute cryptographic keys in accordance with a WSN broadcast key distribution method when used AES and pre distribution key distribution method when used ECC both meet no specific standard 2 CS COP Cryptographic operation with the following component CS COP 1 Cryptographic operation CS COP 1 1 The pSHIELD platform Wireless Sensor Network encrypts and decrypts every message exchanged on network except the sync messages The implemented cryptographic algorithms are AES Advanced Encryption Standard and ECC Elliptic curve cryptography Algorithms are specified by cryptographic key sizes 128 and 256 bits for AES and 160 bits for ECC The use of each algorithm key size is defined according to the specified security level as described in section 5 3 2 4 3 3 Class IA Identification and authentication The families in this class deal with determining and verifying the identity of users determining their authority to interact with the pSHIELD and with the correct association of security attributes for each authorized user and in addiction with Wireless sensor network packets traffic authentication Other requirements classes e g User Data Protection Security Audit are dependent upon correct identification and a
35. ge e minimum password length e password complexity requirements Input data Path to follow and data to fill in the proper fields Procedure 1 Log on as an authorized administrator 2 Click Start point to Settings and click on then Control Panel 3 Double click on Administrative Tools and then on Locla Security Policy 4 In the console tree expand Account Policy and click on Password Policy Output In the right panel of the console password policy enforcing tools appear described as follows e Enforce Password History The Enforce password history setting determines how frequently old passwords can be reused This policy can be used to discourage users from changing back and forth between a set of common passwords Windows XP Professional can store up to 24 passwords for each user in the password history By default this policy is set to zero 0 in Windows XP Professional which disables the RE Issue 1 Page 63 of 68 p SHIELD D6 2 1 RE password history policy e Maximum Password Age The Maximum password age setting determines how long users can keep a password before they have to change it The aim is to periodically force users to change their passwords When this feature is used set a value that makes sense for the specific network environment it is being applied to Generally a shorter period is used when security is very important and a longer period when security is less
36. grity and management of the mechanisms that constitute the SPD functionalities and to the integrity of SPD functionalities data The identified SPD functionalities of these families are implemented in the Central Unit by Operating System Microsoft Windows XP Professional SP 2 CC EAL 4 augmented with ALC_FLR 3 certificated In particular to implement protection of the pSHIELD SPD functionalities the following families and components has been identified 1 PT STM Time stamps with the following components PT STM 1 Reliable time stamps e PT STM 1 1 The SPD functionalities shall be able to provide reliable time stamps 4 3 5 Class SM SPD functions Management Issue 1 This class is intended to specify the management of several aspects of the SPD functionalities SPD attributes data and functions The different management roles and their interaction such as separation of capability can be specified This class has several objectives a management of data which include for example banners b management of SPD attributes which include for example the Access Control Lists and Capability Lists c management of SPD functions which includes for example the selection of functions and rules or conditions influencing the behaviour of the SPD functionalities d definition of security roles The identified SPD functionalities of these families are implemented in the Central Unit by Operating System Microsoft Windows XP
37. h Upper Case Letters A B C Z 2 English Lower Case Letters a b C Z 3 Base ten digits 0 1 2 9 4 Non alphanumeric special characters For example 1 4 RE Page 64 of 68 Issue 1 p SHIELD D6 2 1 RE SM TO2 Purpose Demonstrate the possibility for the authorized administrators to manage local policy which can be used to configure user rights assignment Initialization N A phase Positive test Expected The system is able to determine which users or groups have logon or result task privileges on the computer Input data Path to follow and data to fill in the proper fields Procedure Log on as an authorized administrator 1 Open the Local Security Policy Click Start point to Administrative Tools and then click Local Security Policy This opens the Local Security Settings console Expand Security Settings 3 Within Security Settings expand Local Policies to reveal the Audit User Rights Assignment and Security Options policies 4 Click the User Rights Assignment object Output The details pane will reveal the configurable user rights policy settings as follows described 1 To set a user Logon Right or Privilege double click the desired policy in the details pane This will open the user right Properties dialog window 2 To remove a Logon Right or Privilege for an account click the account name to highlight it and click the Remove button
38. he CC2530DK is Texas Instrument s second generation ZigBee IEEE 802 15 4 compliant System on Chip with an optimized 8051 MCU core and radio for the 2 4 GHz unlicensed ISM SRD band This device enables industrial grade applications by offering state of the art noise immunity excellent link budget operation up to 125 degrees and low voltage operation In addition the CC2530 provides extensive hardware support for packet handling data buffering burst transmissions data encryption data authentication clear channel assessment link quality indication and packet timing information The CC2530 Development Kit includes all the necessary hardware to properly evaluate demonstrate prototype and develop software targeting for IEEE802 15 4 or ZigBee compliant applications The CC2530DK contains the following components e SmartRFO5EB e CC2530 Evaluation Modules e Antennas e CC2531 USB Dongle e Cables RE Page 37 of 68 p SHIELD D6 2 1 RE e Batteries e Documents The SmartRFO5EB evaluation board is the main board in the kit with a wide range of user interfaces 3x16 character serial LCD Full speed USB 2 0 interface UART LEDs Serial Flash Potentiometer Joystick Buttons The EB is the platform for the evaluation modules EM and can be connected to the PC via USB to control the EM The CC2530EM evaluation module contains the RF IC and necessary external components and matching filters for getting the most out of the radio The mod
39. ialization None phase Positive test Expected Verify on packet sniffer application interface the exchange of result messages between Power node and all Sensor Nodes that proves a changing between current levels to desired level Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 1 2 3 4 or 5 stars Procedure With pSHIELD android application change SPD level from the current level to another one From the first level for example as the image below i nil amp 11 59 pSHIEL Security Agent Viewer m Desired SPD level Current SPD level gt It s a Site Local address OKAY IPv4 10 0 2 15 PORT 6000 Output After procedure pSHIELD android application will appear like this RE Issue 1 Page 51 of 68 p SHIELD D6 2 1 RE M M amp 1 18 PSHIELDI Security Agent Viewer Configuration Desired SPD level Wik hk amp Current SPD level Jc cde lei A Fia gt It s a Site Local address OKAY IPv4 10 0 2 15 PORT 6000 Messages caught by packet sniffer regarding to the changing level protocol Pood Time ms b EX 10117 16 31253 Dest Address rox0000 i Destination REESE ms SEE 17 231267 Destinations 0x0000 Power Node and 0x0001 Sensor Node Type 14 Change level and 15 Acknowledge change level E Source 0000 Power Node and 0001 Sensor node No
40. ies have been modeled semantically and their mutual relationships are shown in the following figure RE Issue 1 Page 27 of 68 p SHIELD D6 2 1 RE n n CENTRAL UNIT AUDITING ACCOUNTING Figure 5 6 semantic model of the SPD functionalities The following tests have been done 1 Switch the SPD level to 1 2 Switch the SPD level to 3 3 Switch the SPD level to 5 The following results have been obtained SPD Components Desired SPD 1 Desired SPD 3 Desired SPD 5 AUDITING l AUDITING AUDITING AUDITING AACCOUTING z ACCOUTING gt ACCOUTING ACCOUTING a IDENTIFICATION IDENTIFICATION IDENTIFICATION ire i qo E CRYPTOGRAPHY M rr CRYPTOGRAPHY AES128 CRYPTOGRAPHY AES256 CRYPTOGRAPHY ECC ECIES E L FEY MANAGEMENT LAE 256 Penes KEY MANAGEMENT KEY MANAGEMENT ECC ECIES Figure 5 7 validation results of against the SPD level change Thus an empirical validation of the platform has been done resulting in a successful composition of SPD functionalities While the static process is convincing the main concern is about the time required by the system to enforce the required SPD level After a number of empiric tests we have gathered some statistics showing that the convergence time for the railway scenario ranges from 15 to 60
41. ime system clock synchronization process sees 14 Figure 4 4 Crossbow TEIOSBT0dG LL 15 Figure 5 T BSHIELE ON race 21 Figure 5 2 pSHIELD scenario platform modelling eese 22 Figure 5 3 pSHIELD scenario platform system tree representation sess 23 Figure 5 4 Details of the Discovery core SPD service esse 25 Figure 5 5 Glosed loop SPErleverconiit aca lola 27 Figure 5 6 semantic model of the SPD functionalities s 28 Figure 5 7 validation results of against the SPD level change sees 28 Figure 5 8 Exchange public keys protocol between Power and Sensor Node 30 Figure 5 9 Example of messages exchanged between Power and Sensor nodes 31 Figure 5 10 Power node behaviour UART gt Wireless eee 32 Figure 5 11 Power node behaviour Wireless gt UART eese 33 Figure 5 12 Sensor node behaviour represented as a states machine 34 Figure 5 13 Sensor node behaviour From Power Node reQUESstSs sss 35 Figure amp 1 Tesibed representalioit 1 rsa ME RU IM ERE bUuE pet pK CUR ERE ER URR 38 Issue 1 Page v SEVEN FRAMEWORK PROGRAMME Tables Table 5 1 Com
42. intelligence that drives the composition of the pSHIELD components in order to meet the desired level of SPD This is a software layer as well Personal Area It is a computer network used for communication among computer devices including telephones and personal digital assistants in TIMOR proximity to an individual s body The ZigBee device which is responsible for starting the formation of a PAN ZigBee network The ZigBee PAN coordinator chooses the PAN ID Coordinator There is only one ZigBee PAN Coordinator in any ZigBee network it s ZigBee address is always 0 TinyOS This operating system OS is a free and open source operating system and platform that is designed for WSNs s A period of interaction between users and SPD functional User session components Wireless It consists of spatially distributed autonomous sensors to monitor Senso physical or environmental conditions such as temperature sound vibration pressure motion or pollutants and to cooperatively pass Network 1 their data through the network to a main location RE Issue 1 Page 11 of 68 p SHIELD D6 2 1 RE 4 pSHIELD Scenario Platform 4 1 Introduction pSHIELD project aim to validate and verify the SHIELD integrated system by means of an application scenario In particular the chosen application scenario is the monitoring of freight trains transporting hazardous material In the previously men
43. ity If it isn t correct the message is discarded Otherwise the decrypted message will be send to UART In the case of sync acknowledge messages they are stored in the Power Node as the Sensor Node s public key Sensor Node behaviour Like Power Node also Sensor Nodes have some important actions happening when they receive Power Node s messages or when sensors readings are obtained The Sensor Node behaviour can be described as a state machine like it is showed in diagram in Figure 5 12 When Sensor Node starts it waits for synchronism with Power Node As soon as synchronism is done the sensor node changes to waiting level state where it waits for a set level s message When this one is received the sensor changes to operational mode In this state three actions can occur e Request new sync with the Power Node passing the sensor node back to the waiting level state e Receives a new message to change the level where some actions happen but the operational state is kept e Receives a timer signal after each 120 seconds in order to read the sensor data and send it to OSGI s system RE Page 33 of 68 p SHIELD D6 2 1 RE MODE_WAITING_SYNC Initial receive SyncStartMsg MODE_WAITING_LEVEL receive SetLevelMsg level 0 receive SyncStartMsg receive SetLevelMsg level X encryption level X MODE_OPERATIONAL receive MeasureReqMsg send sensor values Figure 5
44. le the successful attempt by a user to log on the system will be logged as a success audit event Failure audit An audited security access attempt that fails For example if a user tries to access a network drive and fails the attempt will be logged as a failure audit event Input data Path to follow Procedure 1 Logonasan authorized administrator 2 Click Start point to All Programs point to Administrative Tools and select Computer Management 3 In the console tree expand Event Viewer Select Security and in the details pane examine the list of audit events 4 Scroll through the details pane to view the various fields Output The event fields described below The event logs record five types of events Type e Error A significant problem such as loss of data or loss of functionality For example if a service fails to load during startup an error will be logged e Warning An event that is not necessarily significant but may indicate a possible future problem For example when disk space is low a warning will be logged e Information An event that describes the successful operation of an application driver or service For example when a network driver loads successfully an Information event will be logged RE Issue 1 Page 41 of 68 p SHIELD D6 2 1 RE e Success Audit An audited security access attempt that succeeds For example a user s successful attempt to l
45. lities mediated action on behalf of the user itself Output Logon success permit to an authorised user to access SPD functionalities mediated action on behalf of the user itself RE Page 58 of 68 Issue 1 p SHIELD D6 2 1 RE IA T02 Purpose Demonstrate that no SPD functionalities mediated action on behalf of a user can be performed before user is identificated and authenticated Initialization No initialization phase phase negative test Expected A wrong identification and authentication process do not permit a user result to access SPD functionalities mediated action on behalf of the user itself Input data Data to fill in the logon window Procedure Initiate a trusted path for login by pressing CTRL ALT DELETE If the administrator has implemented a log on banner a message banner will appear on the screen Read the message and click OK or hit lt Enter gt to continue with the logon process At the Log On to Windows interface enter the user name for an authorised user and a wrong password e g change the last character of the password Click on the Options gt gt button In the Log on to drop down box select to either log on to the local computer Click OK It appear a logon message with the following contents The system could not logon you Make sure your User name and domain are correct then type your password again Letter in passwords must be typed
46. logy independent 4 ls the orchestration mechanism robust to failures The pShield orchestration mechanisms has been implemented using OSGi as the reference service platform OSGi is characterized by the following advantages OSGi is an open standard OSGi has a number of open source implementation Equinox Oscar Knopflerfish OSGi can be executed even over lightweight nodes Embedded Systems Devices OSGi has been implemented using different programming languages e g Java C C The Java implementations of OSGi is fast to deploy and it is much easier to learn facilitating even an active and collaborative prototype deployment among partners OSGi plugins are available for a number of IDE tools i e Eclipse Visual Studio etc OSGi can be easily deployed in Windows XP 7 Mobile Linux MAC and Google Android OSes More in particular the orchestration platform is based on an open source Knopflerfish OSGi service platform Knopflerfish hereafter referred as to KF is a component based framework for Java in which units of resources called bundles can be installed Bundles can export services or run processes and have their dependencies managed such that a bundle can be expected to have its requirements managed by the container Each bundle can also have its own internal classpath so that it can serve as an independent unit should that be desirable The OSGi environment is robust and secure as deeply analyze
47. mmon platform that constitute the pSHIELD Demonstrator carefully tailored on railway scenario The present document has been focused on i the validation and verification of the integrated platform and ii the validation and verification of its behaviour The objective of the platform validation activity has been focused on checking the consistency of the platform components in terms of functionalities semantic models e g metrics and descriptions and interfaces necessary to enable and perform the SPD composability The objective of the platform verification activity has been to verify the platform behavior with respect to the selected scenario by means of focused functional tests The major platform validation has been based on the presence of the innovative pSHIELD Middleware that is able to dinamically discover and compose the SPD functionalities offered by the system elements This middleware is the first enabler of the SPD aware composability The second enabler is the semantic model used to describe the pSHIELD components and the SPD functionalities since it feeds the metrics driven composition performed at middleware level In conclusion the project demonstrator is able to perform SDP aware composition by usign specific Middleware Services and semantic models and this makes it pSHIELD enabled However this composition can either be correct or not The functional tests have verified that this composition is also correct thus
48. n attempts threshold Page 20 of 68 RE Issue 1 p SHIELD D6 2 1 RE 5 Platform validation process As introduced in chapter 2 the objective of the platform validation activity is to check the consistency of the platform components in terms of functionalities semantic models e g metrics and descriptions and interfaces necessary to perform the SPD composability So these elements are analyzed in this chapter for each component 5 1 pSHIELD Ontology The complete semantic model of the pSHIELD ontology derived from Task 5 1 is depicted in the following figure to Routing Some Loser N Transmissioned T f 7 RELATION h m ompone E valueof Sys A gt P i HO SPDMean __ gt FRI a A kay gt x GeneralFunction sPDConcept ality input j G SPDConser PAL CONSTRAINT A f pe ENS cL e 1 i Ai t sPDFundionalit 4 0 mes T1 snae Y gt Datatype RN Deas p d T Partecipant ServiceGroundin 1S sPDThreat Figure 5 1 pSHIELD Ontology The objective of the demonstrator tailored Ontology will be to represent all and only the information necessary to perform SPD composition of the demonstrator components Since a reduced and simple scenario is considered this model appear to be even too much expressive and only a subset of the foreseen classes and attributes will be instantiated on the basi
49. n be exchanged others types of message e Changing encryption level If there are synchronism between the nodes every time it is requested a change of encryption level by OSGI s system it will send a message for each registered sensor node synchronized with power node with the requested level to Power Node Power Node will forward the message encrypting it before sending Sensor nodes will send back an acknowledge message encrypted on the current level RE Issue 1 Page 31 of 68 p SHIELD D6 2 1 RE to Power Node that will decrypt it and will send back to OSGI s system After OSGI s system receives the acknowledge message from all nodes or a timeout occurs it will send other message from OSGI to Power Node to start encrypting messages in the new level In diagram example the current level is 2 and the requested level is 3 Receiving values from sensors OSGI platform sends each 120 seconds a measures request to each Sensors Node using Power node as forwarder that encrypts the message When each Sensor Node receives this message reads its sensor data and sends them encrypted to the Power Node which decrypts them and sends back to the OSGI In the example diagram the measure messages were encrypted in level 3 5 3 4 1 Power Node behaviour Inside the Power Node predefined actions occur when it receives some message from UART s connection with PC that is executing OSGI s system In the activities diagram in Fig
50. nce of solution Since the algebra is linear and simple the reasoner can perform even a brute force search or an optimized one to search for the corresponding solution and consequently provide and answer in a finite time If the reasoner works for this set of values then it automatically works for each set of values 5 2 Middleware and Overlay for discovery and composition The objective of the Middleware and Overlay platform validation is to focus on the validation of the Core SPD services implemented in the platform The activity is to check the consistency of the platform components in terms of functionalities necessary to perform the SPD composability The needed functionalities are discovery composition and orchestration An additional criteria for the middleware and overlay validation is to validate the middleware architecture as a whole against a SPD level change 5 2 1 Validation against discovery In order to validate the discovery the following criteria have been taken into account 1 Is the discovery mechanism technology independent 2 ls the discovery mechanism using standard protocols 3 Is the discovery mechanism robust to failures The platform discovery functionality is addressed by a discovery framework described in D5 2 For the sake of simplicity the discovery framework is depicted in the above figure RE Page 24 of 68 Issue 1 p SHIELD Issue 1
51. nd its structure Chapter 2 brief introduction Chapter 3 taxonomy Chapter 4 definition and description of platform for pSHIELD scenario Chapter 5 platform for pSHIELD scenario validation process Chapter 6 platform for pSHIELD scenario verification process Chapter 7 validation and verification processes conclusions RE Page 8 of 68 Issue 1 p SHIELD D6 2 1 RE 2 Introduction The pSHIELD activities have lead to the development of a set of technological improvements in the different fields node network and middleware These improvements in a reduced but significant subset have been implemented into the following prototypes pSHIELD Ontology Middleware and Overlay for discovery and composition Cognitive Radio Node Prototype FPGA Power Node Prototype Innovative key Exchange protocol heterogeneous Wireless Sensors Networks and secure communication These prototypes constitute the pSHIELD Technology Demonstrators described in deliverable D6 3 Subsequently some of these elements have been further integrated into a common platform specifically tailored on the railway scenario that constitutes the pSHIELD Integrated Demonstrator This integrated platform will be validated and verified according to specific methodologies In particular The objective of the platform validation activity is to check the consistency of the platform components in terms of functionalities
52. nd testing laboratories can evaluate the products to determine if they actually meet the claims In other words Common Criteria provides assurance that the process of specification implementation and evaluation of a computer security product has been conducted in a rigorous and standard manner Is the possibility to compose different possibly heterogeneous SPD functionalities also referred to as SPD components aiming at Composability achieving in the considered system of Embedded System Devices a target SPD level which satisfies the requirements of the considered scenario Cryptographic Algorithms to hiding the information to provide security and Algorithms information protection against different forms of attacks Provide to the pSHIELD Middleware Adapter the information raw Discovery data description of available hardware resources and services in order to allow the system composability Life Cycle It is the set of elements that support the aspect of establishing support discipline and control in the system refinement processes during its elements development and maintenance In the system life cycle it is distinguished whether it is under the responsibility of the developer or HE Page 10 of 68 Issue 1 p SHIELD RE D6 2 1 the user rather than whether it is located in the development or user environment The point of transition is the moment where the system is handed over to the user Overlay Layer The embedded
53. og on the system will be logged as a Success Audit event e Failure Audit An audited security access attempt that fails For example if a user tries to access a network drive and fails the attempt will be logged as a Failure Audit event Date The date the event took place Source The process that raised the event Time The time the event took place Category The specific class the event is categorized under Event A unique numerical identifier for the event User The user that generated the event Computer The computer on which the event was generated Event details provide more information about events than the Events view This additional information includes the events source a description of the event and details about what is affected by the event To view additional details for an event double click on the event An event Properties window will appear The Description field of the event Properties window provides a longer explanation for the event including what resources are affected and other technical information RE Page 42 of 68 Issue 1 p SHIELD D6 2 1 RE AU T02 Purpose Searching for specific events Initialization No initialization phase phase Positive test Expected The Event Viewer Security let to search for specific events result Input data Path to follow and data to fill in the proper fields Procedure 1 Logonasan authorized administrator
54. on related to SPD relevant activities i e activities controlled by pSHIELD The resulting audit records can be examined to determine which relevant activities took place and which user is responsible for them The identified SPD functionalities of these families are implemented in the Central Unit by Operating System Microsoft Windows XP Professional SP 2 CC EAL 4 augmented with ALC FLR 3 certificated In particular to implement Audit on pSHIELD the following families and components has been identified 1 AU GEN Audit Data generation with the following components AU GEN 1 Audit Data generation e AU GEN 1 1 The SPD functionalities shall be able to generate an audit record of the following auditable events a Start up and shutdown of the audit functions RE Page 16 of 68 Issue 1 p SHIELD D6 2 1 RE b All auditable events for the basic level of audit e AU GEN 1 2 The SPD functionalities shall record within each audit record at least the following information a Date and time of the event type of event subject identity if applicable and the outcome success or failure of the event and b For each audit event type based on the auditable event definitions of the functional components estart up and Shutdown of the audit functions ereading of information from the audit records AU GEN User identity association e AU GEN 2 1 For audit events resulting from actions of identified users the S
55. procedure of test AU TO2 to select Logon Logoff event category Output A logon attempt was made by using a disabled account visible in Properties window number Event 531 and Type Date Time Source Category User Computers information field filled with correct data RE Page 46 of 68 Issue 1 p SHIELD D6 2 1 RE 6 2 2 CS Cryptographic Support CS TO1 Purpose Verify the Power Node synchronization with Sensor Node Initialization Ensure to have assembled CC2530DK device on SmartRF05 Evaluation phase Board connected to a computer and make sure that all system computer and board are set to packet sniffer operating node Errore L origine riferimento non stata trovata Positive test Expected Verify on packet sniffer application interface the exchange of messages result between Power node and Sensor Node that proves the synchronization between these two devices Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 1 2 3 4 or 5 stars Procedure 1 Start TinyOS 2 x Serial Forwarder java net tinyos sf SerialForwarder comm serial dev ttyUSBO telosb 2 Start PShield system knopflerfish container On pShield knopflerfish directory cd osgi sudo java jar framework jar init 3 Change knopflerfish start level of container to level 9 Start android pSHIELD application On avd android emulator directory
56. putable configurations generated by the reasoner sss 24 Table 6 1 Cross reference verification cccccsssescsseccsssescsesesceesessseecesesaesaeeeesaseeceeseesaeseesaeeeseeseesaees 66 Glossary AES Advanced Encryption Standard ECDH Elliptic curve Diffie Hellman ESs Embedded Systems FFD Full Function Device KF Knopflerfish PAN Personal Area Network SPD Security Privacy Dependability WSN Wireless Sensor Network Page vi Issue 1 p SHIELD D6 2 1 RE 1 Executive summary The purpose of this task is to validate and verify the SPD features and concept integrated on an identified platform for pSHIELD scenario The introduction of SPD driven Semantics developed with the target to address the interoperability among different SPD technologies and defined in task 5 1 has solved the challenging problem of the integrated prototypes features considering the heterogeneous environment in which the different modules components have been developed The validation and verification methodology has been defined on the basis of evaluation process defined in task 2 2 multi technology SPD metrics which through the Common Criteria approach builds the basis to provide metrics for the integration and test of the specific components modules which are implemented for demonstration purposes target of task 6 3 The structure and content of the document are the following Chapter 1 purpose of the document a
57. rs that can be dynamically added or deleted to extend the scope of the discovery These adapter are based on specific technology dependent protocols to apply for the real search of available SPD functionalities both locally on single the embedded system as well as remotely over heterogeneous networks in a distributed system of embedded devices The implemented adapters use the Service Location Protocol SLP version 2 It has been defined in RFC 2608 and extended in RFC 3224 SLPv2 allows embedded systems to find services in a local area network without prior configuration SLP has been designed to scale from small unmanaged networks to large enterprise networks RE Page 25 of 68 p SHIELD D6 2 1 RE SLP specifies security mechanisms for authentication and authorization mechanisms and extensive assessment on its reliability can be found on literature On the light of the above considerations it is possible to assert that the platform is validated against the discovery functionality 5 2 2 Validation against composition The composition mechanism relies on the semantic composition thus it has been validated in section 5 1 2 5 2 3 Validation against orchestration In order to validate the orchestration the following criteria have been taken into account 1 ls the orchestration mechanism compliant with standards 2 ls the orchestration mechanism feasible in limited resources devices 3 Is the orchestration mechanism techno
58. rs information field filled with correct data Page 44 of 68 RE Issue 1 p SHIELD D6 2 1 RE AU T04 Purpose Demonstrate that security the security relevant event Logon Failure has been recorded Initialization Execute test IA T01 phase Positive test Expected The security relevant event generated during initialization phase is result recorded in the audit file and the Event Viewer Security log displays it Input data Path to follow and data to fill in the proper fields Procedure Follow the procedure of test AU T01 to reach the Event Viewer console and the procedure of test AU T02 to select Logon Logoff event category Output Logon Failure Unknown user name or bad password visible in Properties window number Event 529 and Type Date Time Source Category User Computers information field filled with correct data RE Issue 1 Page 45 of 68 p SHIELD D6 2 1 RE AU T05 Purpose Demonstrate that the security relevant event Logon attempt has been recorded Initialization Execute test IA TO1 phase Positive test Expected The security relevant event generated during initialization phase is result recorded in the audit file and the Event Viewer Security log displays it Input data Path to follow and data to fill in the proper fields Procedure Follow the procedure of test AU T01 to reach the Event Viewer console and the
59. s KS 1 0 0x0001 P nbr Time ms Dest RX 416 Address 2 16 0x0000 Details of the destination message type and origin of the messages tet a ioi es ia Pakes Source i Destination omag01 eens mE Type and Address Perno i oxoocon Destinations 0x0000 Power Node and 0x0001 Sensor Node Type 0A Synchronization and OB Acknowledge synchronization Source 0000 Power Node and 0001 Sensor node Detail of all message payload and public key exchange in green RE Issue 1 Page 49 of 68 p SHIELD D6 2 1 RE CS T02 Purpose Verify the Power Node synchronization with three Sensor Nodes Initialization Connect three sensor nodes instead of only one phase Positive test Expected Verify on packet sniffer application interface the exchange of result messages between Power node and all Sensor Nodes that proves the synchronization between them Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 1 2 3 4 or 5 stars Procedure The procedure is the same as the test CS T01 Output The output should be similar to test CS T01 output However instead of only a pair of messages for four nodes it gives three pairs Page 50 of 68 RE Issue 1 p SHIELD D6 2 1 RE CS TO3 Purpose Verify the changing of desired level on Power and a Sensor node Init
60. s of the architecture of the demonstration platform The classes and attributes that will not be used will not be instantiated as well without affecting the consistency of the model 5 1 1 Validation against model representation Since the pSHIELD overall semantic model is consistent and has been designed to describe all the potential elements configurations and attributes all its reduced instantiations are validated as well 1 Is the pSHIELD Ontology able to describe the system s components 2 ls the pSHIELD Ontology able to describe the SPD Metrics 3 Is the pSHIELD Ontology able to support SPD Composition according to medieval castle method The expressiveness of the model has been validated at designed level since on a top down approach all the information relevant for the pSHIELD purposes have been included in the RE Issue 1 Page 21 of 68 p SHIELD D6 2 1 RE semantic model Then the consistency of the models has been automatically validated by means of Pellet Reasoner The SPD metrics and the composition method have been included in the model as well by inserting the attribute SPD value and the entity connector that support the composition algebra defined in WP2 On the basis of these argumentations the pSHIELD Ontology is validated against model representation 5 1 2 Validation against SPD Composition The Semantic Engine associated to the selected Ontology will take in input the Scenario parame
61. seconds RE Page 28 of 68 Issue 1 p SHIELD D6 2 1 RE During the transient state the system is always coherent meaning that all the adapters work properly and the overall SPD level is always beyond the starting level On the light of the above consideration we can assert that the platform successfully matches with the validation criteria 5 3 Heterogeneous Wireless Sensors Networks and secure communication 5 3 1 5 3 2 5 3 2 1 5 3 2 2 General Functionality From the WSN point of view the CryptographicHashing has three levels of cryptography e AES 128 the first level of encryption e AES 256 the second level of encryption e ECC ECIES Elliptic Curve Integrated Encryption System 160 as the third and the highest level of encryption for WSN WSN Cryptography levels description In order to define the different cryptography levels in the WSN a predefined security levels was set in the nodes All nodes starts without encryption and only after the framework sets an encryption level the commands for changing encryption are sent via radio and the communication starts to be encrypted This is the approach presented for the demonstrator to easily show the nodes communication without encryption For any different approach or configuration of the start up encryption level it demands minor changes in the nodes firmware Level 1 and 2 AES The Level 1 and 2 uses AES Advanced Encryption Standard a symm
62. sor nodes through special GUI windows for level 1 PSHIELD PowerNode Information Bundle started Changing encryption for the following Node 122 gt Sending LEVEL 1 msg to 1 lt Received LEVEL Ack Msg from 1 Node 1 changed his encryptation to level 1 Received Measure from 1 temperature 32 669999999999995 humidity 29 939 light 28 0 Level 1 Received Measure from 1 temperature 32 68 humidity 30 101 light 31 0 Level 1 Received Measure from 1 temperature 32 74 humidity 30 020000000000003 light 30 0 Level 1 Received Measure from 1 temperature 32 62 humidity 30 262999999999998 light 30 0 Clear Log Hide Me As can be seen the messages should be presented decrypted RE Issue 1 Page 55 of 68 p SHIELD RE D6 2 1 CS TO7 Purpose Verify that data acquired by one Sensor Node are correctly transmitted to OSGI platform and it is level independent Initialization phase Execute the test CS T01 Positive test Expected result Receive on OSGI platform GUI windows sensors measures real values sent over WSN showing level independent similar values Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 1 3 5 stars Procedure Wait for data Output Level 1 Bundle st
63. te Message payload is understandable because it isn t encrypted Page 52 of 68 RE Issue 1 p SHIELD D6 2 1 RE CS T04 Purpose Verify that data transmitted between WSN node is encrypted in level 1 AES 128 Initialization Execute the test CS T01 phase Positive test Expected Verify on packet sniffer application interface the exchange of result messages between Power node and all Sensor Nodes is incomprehensible without decryption when level of encryption is 1 AES 128 Input data Start level for Knopflerfish container 9 Desired SPD level for pSHIELD android application 1 Procedure With pSHIELD android application change SPD level from the current level to level 1 Output Encrypted messages caught by packet sniffer Level of encryption 1 AES 128 Measure message Change level messages P nbr Time ms Dest Rx 62148 Address P nbr Time ms Dest RX 18 Address Type 1E Measure 14 Change level and 15 Acknowledge change level The messages payload of each message has 18 bytes The first byte is TinyOS reserved the second one the message type The other 16 bytes 128 bits are the encrypted message RE Issue 1 Page 53 of 68 p SHIELD D6 2 1 RE CS T05 Purpose Verify that data transmitted between WSN node is encrypted for level 2 AES 256 and level 3 ECC
64. tely by the pShield adapters at middleware network and node layer Current CORE SPD MIDDLEWARE SPD Level OVERLAY NETWORK SERVICES NODE Desired SPD Level Figure 5 5 Closed loop SPD level control From a pragmatic point of view to verify that the Core SPD services are able to maintain a desired SPD level some field tests have been performed Five different types of SPD functionalities have been defined e Audit auditing of user given its account AU e Accounting accounting personnel once identified AU e Identification identification of user identification of sensor IA e Cryptographic support cryptographic algorithms based on a key Exchange CS e Key Management management of keys CS SPD functions Management SM and Protection of SPD functionalities PT have been considered as support functionalities and so have not been included in this paragraph Auditing Accounting have been assumed Central Unit SPD functionalities Identification and Authentication has been considered to be Central Unit and a WSN functionality while Crypto and Key Management have been assumed to be WSN functionalities Three Cryptographic algorithms have been considered AES 128 Advanced Encryption Standard 128 key size SPD metric 1 eAES 256 Advanced Encryption Standard 256 key size SPD metric 3 eECC ECIES Elliptic Curve Integrated Encryption Scheme SPD metric 5 These functionalit
65. ters and is supposed to generate the correct configuration on the basis of the Common Criteria approach and of the desired SPD level The validation against SPD composition should face the following issues 1 ls the SPD reasoner able to compute a solution 2 ls the SPD reasoner able to find always a solution Starting from the pSHIELD scenario platform identified in par 4 2 and SPD functionalities identified in par 4 3 and associated with it the resulting scheme for the medieval castle introduced in D2 2 1 chapter 8 is the following d de Figure 5 2 pSHIELD scenario platform modelling where d SPD identification and authentication measure Central Unit d SPD functions management measure Central Unit ds SPD audit measure Central Unit d4 SPD functionalities protection measure Central Unit ds SPD identification and authentication measure WSN http www mindswap org 2003 pellet RE Page 22 of 68 Issue 1 p SHIELD D6 2 1 RE Issue 1 de SPD cryptographic support measure WSN The correspondent system tree representation of the application scenario is Figure 5 3 pSHIELD scenario platform system tree representation The mathematical expression for the SPD measure of this application scenario system can be defined as follows dior MEAN MIN d d OR OR d MIN d d d dio where dic SPD measures of life cycle documentation In particular considering the pSHIELD sc
66. tioned meaningful scenario the developed SPD functionalities will be integrated in a complete platform which will be validated and verificated In this paragraph the platform and the integrated SPD functionalities are defined 4 2 Platform definition The hypothesized platform is composed by a central unit connected by means of a ciphered wireless network to remote sensors These components are supplied with the related configuration manuals In this platform the assets to protect are data sent by remote sensors to central unit where data are recorded inside the central unit itself Platform logical structure can be represented graphically as depicted in the following figure RE Page 12 of 68 Issue 1 D6 2 1 p SHIELD RE 1 f A i i Sensors 4 Network Central D A x D Configuration Manuals Figure 4 1 Platform structure The detailed composition of the platform components is the following 1 Central unit SENSOR ee N SERVICE rd a reasmy p Central Unit O op Central Unit GUI HP Pavillion DV6 7 C HTC DesireS Intel Core i7 composmon ed ARMv7 1Ghz 4 Gb RAM 768 Mb RAM WinXP mur Android 2 3 3 OS Figure 4 2 Central Unit representation RE Issue 1 Page 13 of 68 p SHIELD D6 2 1 RE The above figure represents the prototype reference schema where the Central Unit box has been expanded to sho
67. ule can be plugged into the SmartRFO5EB Use the EM as reference design for RF layout The CC2531 USB Dongle is a fully operational USB device that can be plugged into a PC The dongle has 2 LEDs two small push buttons and connector holes that allow connection of external sensors or devices The dongle also has a connector for programming and debugging of the CC2531 USB controller The dongle comes preprogrammed with firmware such that it can be used as a packet sniffer device The SmartRF Packet Sniffer is a PC software application used to display and store RF packets captured with a listening RF HW node Various RF protocols are supported The Packet Sniffer filters and decodes packets and displays them in a convenient way with options for filtering and storage to a binary file format The HP laptop connected to the CC2530DK board and where SmartRF packet sniffer application is installed is a HP Compaq nc 6120 with a Pentium M 2 GHz processor and 2GB RAM with Microsoft Windows XP Operating System In the following figure the described testbed deployment TelosB Sensor 01 Sig TelosB Sensor 02 TelosB Sensor 03 Central Unit GUI CC2530DK HP laptop Figure 6 1 Testbed representation RE Page 38 of 68 Issue 1 p SHIELD D6 2 1 RE 6 1 3 Testbed devices initialization Before starting tests session it is necessary to execute the following steps 1 HP Pavillion DV6 series
68. ure 5 10 it s possible to observe that each time that UART sends a message Power Node will do different actions according to the type of message LEVEL_CHANGE_MSG it changes level variable to level got from message and it doesn t do nothing more SYNC START MSG it sets level variable to level 0 adds its public key Power Node to the message and then it acts like other messages Others messages like LEVEL SET MSG they compute CRC of messages encrypt them on the current level and send them to Sensor Nodes by wireless C Q O UART Power Node Wireless I I I receive message I I message SYNC_START_MSG setLevel 0 addPublicKeyToMessage i encrypt send encrypted message rh I I I I I I I I I DE computeCRC I I I I I I I I I Figure 5 10 Power node behaviour UART gt Wireless When Power Node receives messages from Sensor Nodes by wireless its behaviour can be seen in Figure 5 11 Page 32 of 68 RE Issue 1 p SHIELD D6 2 1 5 3 4 2 Issue 1 O C Wireless Power Node UART I i receive encrypted message I decrypt check CRC computeCRC wrong CRC drop message e message SYNC ACK MSG storeSensorNodePublicKey ENNC S send message I Figure 5 11 Power node behaviour Wireless gt UART Firstly it decrypts the message after that it checks the CRC of decrypted message in order to check the message integr
69. uthentication of users in order to be effective The identified SPD functionalities of these families are implemented in the Central Unit by Operating System Microsoft Windows XP Professional SP 2 CC EAL 4 augmented with ALC FLR 3 certificated In particular to implement identification and authentication on pSHIELD the following families and components has been identified 1 IA_UID User Identification with the following components IA UID 1 Timing of identification IA UID 1 1 The SPD functionalities shall allow no SPD functionalities mediated actions on behalf of the user to be performed before the user is identified IA UID 1 2 The SPD functionalities shall require each user to be successfully identified before allowing any other SPD functionalities mediated actions on behalf of that user 2 A UAU User Authentication with the following components IA UAU 1 Timing of authentication IA UID 1 1 The SPD functionalities shall allow no SPD functionalities mediated actions on behalf of the user to be performed before the user is authenticated Page 18 of 68 RE Issue 1 p SHIELD D6 2 1 RE e A UID 1 2 The SPD functionalities shall require each user to be successfully authenticated before allowing any other SPD functionalities mediated actions on behalf of that user 4 3 4 Class PT Protection of the SPD functionalities This class contains families of functional requirements that relate to the inte
70. validating also the metrics composition approach This platform will be the basis of the enrichment and further development that will be carried out during the prosecution of the research with the nSHIELD project RE Issue 1 Page 67 of 68 p SHIELD D6 2 1 RE 1 2 3 4 5 6 7 8 9 10 11 References Windows XP Professional with SP2 Evaluated Configuration User s Guide version 3 0 July 11 2007 MOTE IV Telos revB Low Power Wireless Sensor Module Manual CROSSBOW TPR2400 2420 Quick Start Guide Rev A May 2005 Doc 7430 0380 01 H Wang B Sheng C C Tan and Qun Li WM ECC an Elliptic Curve Cryptograph Suite on Sensor Motes Technical report Oct 30 2007 V Casola A De Benedictis A Mazzeo and N Mazzocca SeNsIM SEC security in heterogeneous sensor networks May 2011 SARSSI201 1 TinyOs http www tinyos net Cryptography algorithms for TinyOS http tinyos cvs sourceforge net viewvc tinyos tinyos 2 x contrib crypto index html TinyECC A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks http discovery csc ncsu edu software TinyECC Windows XP Professional Security configuration guide version 3 0 July 18 2007 SmartRF packet sniffer user manual SWRU187F Texas Instruments revision F July 07 2011 CC2530 Development kit user s guide SWRU208b Texas Instruments revision B April
71. w the hardware components used in the testbed It is composed by a Central Unit machine and an USB connected mobile terminal Due to the need of having a high performance system the Central Unit machine is a HP Pavillion DV6 series equipped with a top gamma Intel Core 17 quad processor with 4 Gbyte DDR3 RAM and the Operating System is Microsoft Windows XP The OSGi environment runs over the JVM version 1 6 that has been installed in the Central Unit The Knopflerfish Java based implementation of the OSGi has been used The whole pShield middleware has been made to run into the same OSGi container The Central Unit real time system clock has been synchronized via the USB connection with the external GSM device Fig 4 3 eee CENTRAL QUE DAORUE UNIT x SENSOR O NTP CLIENT Connectedto the NTP Server via the PAN createdwith the mobile device NTP SERVER The NTPD daemon Is running in the Android device as A Linux process BASE STATION Network Operator Providing the Network Identity and Time Zone Figure 4 3 Real time system clock synchronization process As shown in the above figure once the mobile device is connected via the USB cable the Windows XP Android driver establishes a virtual Personal Area Network PAN and an internal IP addressing scheme is associated to the mobile device and to the Central Unit It allows the mobile device to act as a NTP server over the IP based PAN The Central Unit runs an
72. y is identified 6 1 2 Testbed definition Issue 1 In order to achieve tests for pSHIELD platform verification the following deployment and devices were used Wireless Sensor Network WSN in the star topology In the star topology the communication is established between devices and a single central controller called the Power noed The Power node is maintained powered while the devices are AA battery powered After the FFD full function device is activated for the first time it establishes its own network and becomes the PAN coordinator The start network chooses a PAN identifier which is not currently used by any other network within the radio sphere of influ7ence This ensure us that each star network operates independently The WSN is composed by three Crossbow TelosB devices powered by two AA batteries and a TelosB plugged into USB laptop port as Power node See 4 2 paragraph for TelosB technical specifications The laptop composing the Central Unit is a HP Pavillion DV6 series equipped with a Intel Core I7 quad processor with 4 Gbyte DDR3 RAM and Microsoft Windows XP Operating System in certified configuration which provides a set of security functions verified in the following tests The Central Unit GUI is provided by a HTC Desire S mobile terminal equipped with a ARMv7 1Ghz processor and 768 Mbyte RAM This terminal is connected to the laptop by a usb cable and acts as NTP server too See 4 2 paragraph for more detail T

Download Pdf Manuals

Related Search

Related Contents

取扱説明書 - SANUS    Samsung SGH-D980 Kasutusjuhend    RCD-2650 b  Bei einigen Menschen kann es zu epileptischen Anfällen oder  User Manual  Bretford 42-Unit Intellihent Netbook Cart  hoja técnica para imprimir  

Copyright © All rights reserved. Failed to retrieve file