1. ONIE for QCA ARM based AP platforms
JVR Murthy
Mojo Networks

2. Agenda
ONIE support for QCA ARM AP platforms
Secure ONIE for WiFi APs

3. QCA ARM AP Flash layout with ONIE + Vendor NOS#1 #2 #3 #4 #7 #8 #9
U-boot bootloader
binary
U-boot Environment Vars
ONIE Kernel
initramfs
kernel
Vendor NOS
rootfs ….
mibib
ddr
ssd tz
rpm
bootconfig
Sbl1,2,3

4. (BootLoader/Kernel patches, Platform initialization etc)
ONIE support for QCA ARM AP platforms
ONIE Repository and Build system comprises of :
Platform independent functionality for Network OS (NOS) installer discovery, ONIE update, NOS erase etc.
Well defined hooks and mechanisms to add support for a particular platform i.e. Bootloader, Kernel, Ethernet drivers etc.
ONIE Repository
&
Build System
Support for Platform X
(BootLoader/Kernel patches,
Ethernet drivers,
Platform initialization etc)
ONIE Build
For
Platform X
Goal
Create ONIE builds for Qualcomm AP platforms such that ONIE can be easily adopted by HW vendors
Adoption by HW vendors is important

5. Add QCA AP platform support in ONIE build system Sub Approaches
Prepare platform specific patches from Qualcomm SDK (QSDK)
Utilize Open Source code base from OpenWRT, LEDE, CBW-Linux etc.
Mojo has been working on adding platform build support for EdgeCore’s EAP ac Wave2 4x4 AP using approach A i.e. QSDK. This is close to completion.
Challenges
Even after successful completion of this project, we cannot contribute it to ONIE repository due to licensing issues of Qualcomm SDK (QSDK). Refer Figure 1.
An ONIE build utilizing available open source codebase may be possible but support for various, especially newer, platforms may be restricted
Also, this open source approach might be ok for a PoC but unlikely to be embraced by HW Vendors for productization
Home grade SDK vs Enterprise grade SDK

6. QCA ARM AP Flash layout with ONIE + Vendor NOS
Approach #1….contd
An ONIE image for Qualcomm ARM based APs comprises of :
SBL partitions +
U-boot +
Kernel/InitRamFS
All these components are either derived directly or contain patches from licensed Qualcomm SDK and hence cannot be submitted to ONIE repository
QCA ARM AP Flash layout with ONIE + Vendor NOS #1 #2 #3 #4 #7 #8 #9
U-boot bootloader
U-boot Environment Vars
ONIE Kernel
initramfs
kernel
Vendor NOS
rootfs ….
mibib tz
bootcfg
ddr
ssd
rpm
Sbl1,2,3
Figure 1
SBL Partitions

7. ONIE Build For Qualcomm AP
Approach #2 :
Add ONIE build option to OpenWRT based Qualcomm SDK (QSDK)
ONIE
Repository
Step 1 : Pull ONIE repo
OpenWRT based
Qualcomm SDK
w/ ONIE build option
ONIE Build
For
Qualcomm AP
Step 2 : Build and combine platform independent ONIE scripts, utilities etc. with QSDK platform components
Approach #1 is somewhat re-inventing the wheel because QSDK has already built u-boot, kernel, ethernet drivers etc. for the platform
BRCM has also apparently taken this approach

8. Approach #2....contd
Pros :
No licensing issues related to QSDK
Scaleable Model - ONIE build available immediately for every Qualcomm reference AP platform
Lowers adoption barrier for HW vendors by leveraging their familiarity with QSDK
Enables ONIE and QSDK development to happen in parallel
Considerations :
Available to QSDK licensees.
New ONIE adoption & build model.
Need to consider if existing ONIE code structure needs modifications to support this
Next Steps :
Meeting proposed with Qualcomm to present and discuss this proposal

9. Secure ONIE for WiFi APs

10. Secure ONIE for WiFi APs
Need for security
Numerous devices installed at varied locations
Possibility of physical access to the devices
Automated installation / upgrades at large scale is a MUST introducing security risk
Secure installation/upgrade
Verify ONIE image before upgrade
Verify NOS image before installation/upgrade
Secure boot
Verify ONIE/NOS image at boot time to avoid booting into tampered image

11. Proposal for secure installation of NOS
Use PKI and a pre-installed database of certificates on the device
NOS vendor signs the NOS installer bundle with the private key corresponding to the pre-installed certificate on the device
ONIE downloads the NOS installer and validates the digital signature using the certificate on the device
ONIE verifies the identity of the NOS image provider (using CN in the certificate) by comparing it with the value provided

12. NOS installer verification steps
User specifies (via u-Boot or DHCP params) whether signature verification should be done (default yes) and if so, which publisher is expected (default ANY).
ONIE constructs URL for NOS installer as usual and appends with .sig to form NOS installer signature URL.
ONIE script uses OpenSSL (smime sub-utility) to verify signature and certificate chain and extract certificate of publisher from the signature file.
signature file expected in PKCS#7 format.
ONIE verifies that the CN in the publisher’s certificate matches user specified value.
ONIE executes NOS installer script.

13. NOS Installer’s responsibility
NOS installer should verify signature and publisher of any other image files that it downloads.
User specified publisher name can be made available as an environment variable or similar.
ONIE (shell) library functions can make this verification task simpler.
Thus ONIE assures trustworthy NOS installer and NOS installer assures trustworthy NOS image.
Caveat: It is assumed that DHCP (on the LAN) is secured.

14. Secure boot
Use PKI based digital signature verification of images on flash
Use a pre-installed database of certificates
Uboot verifies ONIE or NOS image during device boot
Halts the boot process if validation fails

15. Establishing chain of trust - approach #1
Software based validation starting from locked down uboot
Install root certificates on a flash partition
Lock u-boot and linux root prompt to prevent
Tampering of certificates
Flashing arbitrary images
Secure boot: Uboot verifies ONIE or NOS image before booting
Secure install: ONIE verifies NOS installer before installing it
Certificate generation
ODM vendor generates the root CA, signed uboot and ONIE images
NOS vendor get a CA derived from root CA of ODM for singing NOS images
Pros: No hardware support required, relatively simpler
Cons: Tampering via JTAG etc interfaces is possible

16. Establishing chain of trust - approach #2
Hardware based chain of trust
Use the underlying hardware mechanism to extend the chain of trust from hardware to linux kernel (ONIE / NOS)
E.g. ARM TZ as implemented by QCA
Root CA hashes need to be programmed into the ROM during manufacturing
Uboot and kernel uses the underlying security mechanism to validate digital signatures (E.g TZ SCM interface of QCA)
Secure boot: ROM PBL → SBL1/2/3 → Uboot → Linux (ONIE/NOS)
Secure install: ONIE verifies NOS installer using underlying security mechanism
Certificate generation
ODM vendor generates the root CA and programs the certificate hash into the ROM
NOS vendor gets a CA derived from root CA of ODM for singing NOS images
Pros: Fully tamper proof
Cons: Requires hardware support, relatively complex to implement

17. Thank you