Boot to Cloud Security Considerations with IoT.pdf

《Boot to Cloud Security Considerations with IoT.pdf》由會員分享，可在線閱讀，更多相關《Boot to Cloud Security Considerations with IoT.pdf（33頁珍藏版）》請在三個皮匠報告上搜索。

1、Boot to Cloud Security Considerations with IoTKevin TownsendZephyr Developer SummitPrague,28 June 2023About MeTech Lead at Linaro,focusing on Arm,RTOS,and IoT Security15 years of full time open source developmentZephyr maintainer for Aarch32,TF-M,zscilibGithub:microbuilderAgendaSecure BootDevice Pro

2、visioningStorage-Free Key DerivationSecuring Data in TransitSecuring Data at RestExample:Confidential AIChecklistCore Components in a Secure IoT SystemSecure BootCore Components in a Secure IoT SystemSecure BootAs the root of trust this is the most critical component in a secure system!Shouldnt be a

3、n afterthought!Test early and test oftenIn the case of Zephyr,this is often MCUBoot,though not alwaysSecure means immutableShould only run valid signed,and ideally versioned imagesMay include rollback protection(MCU_DOWNGRADE_PROTECTION w/MCUBoot)Image contents and signature must be verified every r

4、esetShould support image encryption for safer firmware deliveryMay include limited HW recovery option(serial recovery on GPIO pin on MCUBoot)Secure boot requires protecting the bootloader flash region from overwrites!Must disable SoC device-recovery and debug interfaces on the MCU!MCUBoot:mcumgrMCUB

5、oot CLI management toolMulti transport:Serial,BLE,UDPExtensible command set:Set datetimeUpdate file systemGet thread/device statsReset deviceShell access The optional commands are a double-edged sword and need to be evaluated against your deployment scenario!MCUBoot:imgtoolGenerates correctly-format

6、ted keys$imgtool keygen-k sign_p256.pem-t ecdsa-p256Signs imagesCan be used to verify signaturesGet C-friendly public/private key data:$imgtool getpriv-k sign_p256.pem$imgtool getpub-k sign_p256.pem Always generate and safely store your own private signing key!Point the build system to it via BOOT_S

7、IGNATURE_KEY_FILE.Device ProvisioningCore Components in a Secure IoT SystemCommon Provisioning Scenarios There is no one-size-fits-all approach here!Can you use a public cloud provider?EU-only?Where is data stored?Does everything need to exist behind a company firewall?What kind and how many keys/ce

8、rts are required,and how often will they change?What level of access control is required?Who can provision devices?When/where?There are two common scenarios for provisioning devices:Factory provisioningDevices are provisioned in the factory,during HW manufacture or when packaging,Late-bindingDevices

9、 are provisioned in the field by the customer,generally w/an intermediary toolLate-binding is probably the more common scenario in shipping productsSignpost:Open Provisioning StandardsFIDO Device Onboard 1.1“An automatic onboarding protocol for IoT devices.Permits late binding of device credentials,

10、so that onemanufactured device may onboard,without modification,to many different IOT platforms.”A simpler solution may also be appropriate,which well discuss later with the Confidential AI sample.Specification DocumentBest Practice:Storage-Free Key DerivationMultiple keys are often requiredSafest w

11、ay to store a key is never store it!Device-bound keys derived w/HUKKey(s)get regenerated at bootPersistent across FW updatesTies encryption/auth/etc to MCU This approach requires that the Hardware Unique Key is protected!With S/NS firmware,always prepend a value to the Info label in S!This same appr

12、oach can also be used to derive a device-bound UUID!RFC 5869Securing Data in TransitCore Components in a Secure IoT Systemtl;dr:Just use TLS!If you can use it,TLS is your best line of defense for connection-based dataUniversally adopted,reliable,and based on modern encryption standardsExplicitly enf

13、orce a recent version(=TLS 1.2)where possibleBasic TLS example:samples/net/sockets/http_get Basic TLSBasic TLS authentication validates the SERVER identityThe certificate exchange gives us a certain degree of confidence in who were talking to,based on the trust we place in the certificate authorityB

14、asic TLSSigned by aTrusted CAContains the CAs public key to verify the server certificates signature key derivation symmetric encryption of data Best Practice:Mutual TLSHow does the server know its talking to a trusted client device?TLS optionally includes Client Authentication,where the server also

15、 asks the client device to provide proof of its identity Mutual TLS is part of the TLS standard,but commercial cloud provider support levels vary!Some providers(Azure IoT Hub,for example)have better X.509 client certificate authentication support than others for.Mutual TLSAlso signed by CA key deriv

16、ation,etc.Basic Client Authentication We can insert additional claims into the client cert,such as a unique device ID,or make use of the unique certificate serial number.key derivation,etc.Mutual TLS Sample CodeCertificate generation script and TCP server sample code: 2022:X.509 Client Authenticatio

17、n in Zephyrhttps:/ Data at RestCOSE Payload EncryptionWhat do we do when TLS isnt available?Examples:Secrets in external flash,intermediary broker app(BLE),etc.Securing data at rest is less of a solved problem todayCOSE the only open,embedded-appropriate std Im aware of for data at restCOSE is built

18、 on top of CBOR,which is essentially binary JSONCOSE allows for signing and encryption of data at rest using modern cyphersShould be actively promoted as a solution to securing data at restCOSE encryption less common than signing todayPoor ENCRYPT/ENCRYPT0 library supportC libraries like t_cose are

19、making an effort to improve this,but an active WIP No profiles in COSE,so you need to know what youre doing piecing things!COSE Payload EncryptionRust PoC of using COSE for encrypting data at rest(flow,CEDAR):https:/ initial proposal for Efficient COSE encryption:LHR23-313:Secure IoT Data FlowDavid

20、Brown,Linaro Connect 2023https:/resources.linaro.org/en/resource/k9iN8sdePtvXWTN1mP1tKPExample:Confidential AIWhat is Confidential AI?An attempt to demonstrate end-to-end security best practices based on modern Cortex-M hardware(v8-M,TrustZone,etc.)using open source software and open standards with

21、AI/ML workloads as a test caseTheres nothing magic about the AI/ML component!Engineering outputs justtend to improve when you have a clear,specific problem to solve.Confidential AI System ArchitectureConfidential AI Proof of Concept Application:https:/ Source Components:LITE Bootstraphttps:/ RTOShtt

22、ps:/ contact details:confidential_ailinaro.orgApplication Code and Component RepositoriesChecklistChecklistIntegrate bootloader early on!Understand your provisioning requirementsReplace default keys from day one,even during dev!Plan for key storage(harder to leak keys you never store!)Streaming data?Use TLS 1.2!Using TLS?Dont needlessly reinvent client auth!Data at rest still a WIP,but COSE is the standard to watchThank you