CENTER FOR ASSURANCE RESEARCH AND ENGINEERING
Volgenau School of Engineering
LEARN MOREVisit us online at care.vse.gmu.edu.
4400 University Drive
Fairfax, Virginia 22030
Volgenau School of Engineering
LeveragingBlockchain-basedprotocolsinIoT systems
Angelos Stavrou
TalkOutline
• OverviewofIoT
• SecurityFailuresinIoT:MotivatingUseCases
• WhydirectuseofBlockchain isnotpracticalforIoT
• Challenge:DesignpracticalBlockchain-basedprotocolsforIoT
• Conclusions,Discussion&Challenges
2
InternetofThingsDefined
• KevinAshtonintroducedthetermInternetofThings(IoT)in1999
• Networkofdevicesabletoconfigurethemselvesautomatically
• Humanisnotthecenterofthesystem
• Motivation:Betterunderstandingoftheenvironmentandresponsetocertainevents.Machinesaredoingbetterinsensing&reportingonconditions
• Fact:ApplicationsoftraditionalInternetaredifferentthantheapplicationsofIoT
3
What is the Fundamental Problem?• Devices operate using non-verified or tested software
- outdated software- custom-made software- software from many vendors- modular software from many different vendors- poorly tested software- software that was designed for a different set ofrequirements
- unpredictable & chaotic software
Cyber Security is not a Design Tenet
ThereisNOIndustryincentivetobuildSecureSystems(SoftwareorHardware)4
WhattheFutureHolds
5
Drivables Flyables
Scannables Wearables
TheGrowthofIoT
6
SectorsofIoT Applications
Smart Home
Home automation
Energy efficiency
Home security
Transportation
Road safety
Traffic regulation
Law enforcement
Retail
Automatic payments
Efficient cataloguing
Shipment tracking
Industry
Quality assurance
Failure prediction
Productivity improvement
Healthcare
Condition monitoring
Remote treatment
Personalized advices
7
Sensors&Actuators
Sensors Actuators
8
Connectivity
WA
NPA
NLA
N
IPv6
9
TalkOutline
• OverviewofIoT
• SecurityFailuresinIoT:MotivatingUseCases
• WhydirectuseofBlockchain isnotpracticalforIoT
• Challenge:DesignpracticalBlockchain-basedprotocolsforIoT
• Conclusions,Discussion&Challenges
10
CommonSecurityIncidents
90%
Private Data Collection Insecure Interfaces Unencrypted Communications
Weak Requirements
60% 70% 80%
11
Top10Vulnerabilities(OWASP)
Insecure Web InterfacesDefault accounts, XSS, SQL injection
Inefficient Authentication/AuthorizationWeak passwords, no two-factor authentication
Insecure Network ServicesPorts open, use of UPnP, DoS attacks
Lack of Transport EncryptionNo use of TLS, misconfigured TLS, custom encryption
Private DataUnnecessary private information collected
Insecure Cloud InterfacesDefault accounts, no lockout
Inefficient Mobile InterfacesWeak passwords, no two-factor authentication
Insufficient Security ConfigurabilityPorts open, use of UPnP, DoS attacks
Insecure Software/FirmwareOld device firmware, unprotected device updates
Poor Physical SecurityExposed USB ports, administrative accounts
12
UseCase:BluetoothLowEnergyBeacons
• Beacons Purpose:– Provide inexpensive remote identification– Proximity estimation– Low power consumption
• BLE modules are integrated with smartphone devices
• Hardware requires very little energy– Easy to maintain and have a small footprint
• Achieve accurate proximity estimation even in indoor scenarios
– Better than GPS
• Identification can be achieved across considerable distances– Better than RFID
13
WhatCanGoWrong?• ExistingBLEBeaconspecificationsnaivelyomitprotectioninmessagestructure– Apple’siBeacon,Google’sEddystone,Altbeacon
• VendorsclaimthatBLEBeaconapplicationsarenotsecurity&privacysensitive
• CurrentApplicationscanbeabused– Denialofserviceorlossofrevenue
• Whataboutfutureapplications?– Automaticpayments– AutomaticCheck-In– AuthorizationtoRestrictedAreas– Accesscontroltodevices(e.g.workstation) 14
UnderlyingDesignProblem
• Transmissionofastaticidentifier• Constantbroadcastingofthatidentifier• Longrangetransmissions(75meters)
15
AttackerCapabilities
•Open source software for monitoring– Bluez, Ubertooth, others
•Inexpensive hardware–USB adapter (Sena UD100 Long
Range Bluetooth 4.0 Class1 USB adapter)
–High gain antennas (RP-SMA 2.4GHz 7 DBI)
–Discrete portable devices (e.g. Raspberry Pi)
16
Attack:UserProfiling
17
Attack:PresenceInference
• Tracking & Reporting the presence of a target within an area
• Target must carry a portable, beacon-emitting object
• Inexpensive equipment can boost the range to more than 300 meters radius • Typical range is 75 meters
18
WhynotUseCryptography?
19
RSA1024RuntimeOverhead:
SomeofthetraditionalCryptoistoo“expensive”forembeddeddevices
SurveyofCryptoSupportinIoT
20
Brand Name CPU Freq. Sram FlashCryptoAcc. EnergySource
PublicKeyCrypto
Belkin WeMoSwitch RalinkRT5350F(MIPS) 360Hz 32MB 16MB No Wallsocket Yes
Samsung SmarthingsHub
PIC32MX695F-512H 80MHz 128KB 512K No Wallsocket/Battery Yes
Nest ThermostatTIAM3703CUSSitara(ARMCortexA8)
1GHz 512Mb 2Gb Yes Wallsocket Yes
LIFX Color1000 KinetisK22(ARMCortex-M4)
120MHz 128KB 512K No Wallsocket No
Amazon EchoTIDM3725CUS100(ARMCortexA8)
1GHz 256MB 4GB Yes Wallsocket Yes
Philips HueLightsSTMic.STM32F217VE(ARMCortex-M3)
120MHz 128KB 1MB Yes Wallsocket Yes
Philips HueLights(Bulb)
STM32F100RBT6B(ARMCortex-M3)
24MHz 8KB 128KB No Wallsocket No
Nest Smoke/CarbonAlarm
FreescaleSCK60DN512VLL10customKinetisK60
100MHz&48MHz
128KB 512K Yes Wallsocket/Battery Yes
Pebble TimeSTMicroSTM32F439ZG
(ARMCortexM4)180MHz 256KB 2MB Yes Battery No
Adafruit FeatherMOBluefruitLE
TSAMD21G18ARMCortexM0
48MHz 32KB 256KB No Battery No
BeagleBone GreenWireless(othermodels)
AM335x1GHzARMCortex-A8
1GHz512MB
4GBeMMC Yes External/Battery Yes
RaspberryPi Zero ARM1176JZFSArmv6core 1GHz 512MB MicroSD
Yes External/Battery Yes
RaspberryPi Two(2) ARMCortex-A7 900MHz 1GB MicroSD Yes External/Battery YesRaspberryPi Three(3) ARMCortex-A53 1.2GHz 512MB MicroSD Yes External/Battery Yes
Arduino MKR1000(othermodels)
Atmel|SMARTSAMD21Cortex-M0+
32KHz&48MHz
32KB 256KB No Battery No
Fitbit One STMic.32L151C6UltraLowP.ARMCortexM3
32MHz 16KB 128KB No Battery No
Fitbit SurgeSiliconLabsEFM32(ARMCortex-M3)
48MHz 128KB 1MB Yes Battery No
TalkOutline
• OverviewofIoT
• SecurityFailuresinIoT:MotivatingUseCases
• WhydirectuseofBlockchain isnotpracticalforIoT
• Challenge:DesignpracticalBlockchain-basedprotocolsforIoT
• Conclusions,Discussion&Challenges
21
CanweuseBlockchain-inspiredprotocols?
22
• Trust among untrusted Parties• Distributed resilience and control• Fully Decentralized network• Primarily Open source• Security and modern cryptography• Controlled & Open Participation• Smart Contracts• Dynamic and Fluid Operation
Strengths
Whatdowereally need?
23
IoT SystemOperationalRequirements(Empirical)
• Dynamicbutverifiablegroupmembership
• Authentication&Dataintegrity• Secureagainstsingle-node(orsmallsub-setofnodes)keyleakage
• Lightweightoperationsintermsofresources
• Encryptionisaplusbutnotfirmrequirement
• Capableofhandlingsensor“sleep/power-off”periods• Handleresourcediversityanddataofsensorsandaggregators
24
PublicDistributedVerifiableCryptographicLeger• Public
• Allparticipantsgainaccessto“read”
• Distributed• Peer-to-PeerDataCommunication,FullyDecentralized
• Cryptographic• Digitallysignedtransactions,proof-of-worklimitsrateofinput
• Ledger• VerifiableTransactionalDatabase
BlockchainPrimer
25
BlockchainPrimer
Blockchain Primer
26
Blockchain Blocksv Sequencesofsignedandverifiedtransactionsv Publishedanddistributedgloballyv Magicnumber,Sizev Header
• Hashofpreviousblock(chain)• Merkle roothashofblock• Timestamp• Target,nonce(mining)
v Numberandlistoftransactions
27
Blockchain Primer
TalkOutline
• OverviewofIoT
• SecurityFailuresinIoT:MotivatingUseCases
• WhydirectuseofBlockchain isnotpracticalforIoT
• Challenge:DesignpracticalBlockchain-basedprotocolsforIoT
• Conclusions,Discussion&Challenges
28
IsBlockchain DirectlyApplicableinIoT?
29
DesirableProperties• Distributedprotocolwithverifiabletransactionhistory• Dynamicmembershipmulti-partysignatures
UndesirableProperties• Requiresproofof“work”• RequiresPKI• SizeoftheLedgeranissuefor“small”devices• Anonymous(unverifiable)Join/Leaveoperations
Whatcanwedo?
30
Eliminateundesirableproperties• Requiresproofof“work”
Requiresproofofearlierparticipationusinghistory
• RequiresPKIHash-basedsignatures(orotherMerkle-treeschemes)
• SizeoftheLedgeranissuefor“small”devicesPruneandCompressLedger.Maintainonlydevice-relevanttransactionledgerwhendeviceistooresourceconstrained
• Anonymous(unverifiable)Join/LeaveoperationsGroupsignaturesusingpre-sharedgroupKey(s)
Hash-Chains
31
Hash-Chain:PreImage Path
32
Hash-Chain:PreImage Cost
33
But what about in practice?
For sensor nodes and aggregators:
Using Hash chain of size: 232 = 4,294,967,296 passwords • More than 68 years to run out for one (1) transaction per second • Each transaction having a distinct key
IfweselectSHA256asthehashfunctionofchoice:MemoryRequirements:2xlog2(n)+256=320bitsFor32locations+seedtotaling1,320bytesofstorageor1.3KB
TypicalSensorNetworks
34
Sensor Sensor Sensor
Aggregator
Sensor Sensor
Aggregator
Sensor
Sensor
Sensor
Aggregator
Aggregator
SensorSensor
Aggregator
Blockchain-basedProtocolforIoT?
35
WesuggestaBlockchain-basedprotocolthatusesthefollowingblocks:
xi = H (Data ||KG ||H (zi )n ),H (zi )
n−1
H = Hash, KG = group Key, zi = sensor i "public key"
36
WesuggestaBlockchain-basedprotocolthatusesthefollowingblocks:
Blockchain-basedProtocolforIoT?
37
• IoT SystemOperationalRequirements(Empirical)• Dynamicbutverifiablegroupmembership• Secureagainstsingle-node(orsmallsub-setofnodes)keyleakage
• OnlyAggregatorscanaddnodesbyissuingagroupKey• CanbedoneusingSymmetricEncryptionoraHashChain• NodeisverifiedbothbygroupkeyANDby participationhistory• Toaddanode,anadversarywillhaveto:
a)Compromisethegroupkeyb)Issuean“addnode”transactionc)Addasensornode
• Shapeofthetreeshows“additions”and“removals”ofnodesovertime
DoestheSchemeMeettheRequirements?
38
• IoT SystemOperationalRequirements(Empirical)• Authentication&Transactionintegrity
• NodesandtransactionsareauthenticatedusingthegroupkeyandthenodeLamport signatures
• AnodeuseshisLamport publickeytovalidateinsertedDATA,transmitsDATAtoaggregator(s)
• Lightweightoperationsintermsofresources• Operationscanbelightweightforsensors.Aggregatorshavemoreresources
• Encryptionisaplusbutnotfirmrequirement• Noneedforencryption
DoestheSchemeMeettheRequirements?
DoestheSchemeMeettheRequirements?
39
• IoT SystemOperationalRequirements(Empirical)• Capableofhandlingsensor“sleep/power-off”periods
• Nodescanre-authenticateusingtheirknowledgeofhistoricaltransactionsprovingtheirmembershipspecifichistoricaltransactionsusingpredecessors forLamport Signatures
• Handleresourcediversityanddataofsensorsandaggregators• Differentnodesstoredifferentportionsoftheledger• Aggregatorsfully,otherspartial
TalkOutline
• OverviewofIoT
• SecurityFailuresinIoT:MotivatingUseCases
• WhydirectuseofBlockchain isnotpracticalforIoT
• Challenge:DesignpracticalBlockchain-basedprotocolsforIoT
• Conclusions,Discussion&Challenges
40
Conclusions
• IoT Scale,Vendors,Technologiesincreaseexponentially• IoT Deviceswillalwayshavediversecapabilities&Resources• UseofCryptographyisdonewithoutclearunderstandingoftheimplications
• NoCurrentStandardsforLightweightcryptography
• Blockchain inspiredprotocolscombinedwithnewCryptographicprimitivesmightbethepathforward
41
Discussion
NowthatwebuildaBlockchain forIoT whatisnext?
• SecureSoftwareUpdatesandTransactionalCross-IoT• Audit&MonitorDevicesfromdifferentVendors• EnableApplicationMarketsforIoT• ShareinformationusingBlockchain SmartContracts• VerifiedTimeforIoT
42
AreweDone?Challenges
43
CostofDeployment&EnergyisanopenproblemforIoTdevices,Consumerproducts
Bi-directonality ofcommunicationsScalinglatencyNomsec ornsectransactionsTimeVerification
Privacy&SecurityisnotjustimmutabilityWhataboutdataprovenanceandremoval?Blockchain isforever
Competingtechnologiesarecausingconfusionanddonotoffercompletesolutionsforuserneeds
LackofStandardsandmaturityoftechnologiesanimpedimentforadoption
NovelBlockchain-inspireddesignsthatadheretorequirementsoftheusecases
Scalability&InteroperabilitynotinitialdesigntenetsCommunicationOverhead
Thankyou,Questions?
OperationalTransactions
45