Czy zastanawiałeś się kiedyś, jakie funkcjonalności realizuje nowoczesne oprogramowanie układowe?
Zapraszamy na prezentację poświęconą technologii ARM Trusted Firmware, na którym opowiemy w jaki sposób nowoczesne systemy radzą sobie z kwestiami bezpieczeństwa na przykładzie ARM Trusted Firmware. Zaprezentujemy także różnice między światem zaufanym a światem normalnym, czy i jak te dwa światy są w stanie istnieć w jednym systemie oraz co je łączy.
3. Plan prezentacji
1. Wstęp - tryby pracy procesora
2. ARM Trusted Firmware od środka
3. Bootloadery ARM-TF
4. Secure boot w ARM-TF
5. Runtime ARM-TF a bezpieczeństwo
4. Plan prezentacji
1. Wstęp - tryby pracy procesora
2. ARM Trusted Firmware od środka
3. Bootloadery ARM-TF
4. Secure boot w ARM-TF
5. Runtime ARM-TF a bezpieczeństwo
5. Tryby pracy procesora? A po co?
● Procesor = kilka trybów pracy
● Separacja dostępu na poziomie CPU - zakres operacji per proces
● Pozwalają np. na sprzętową kontrolę dostępu do pamięci
https://rhelblog.files.wordpress.com/2015/07/user-space-vs-kernel-space-simple-container.png
6. Tryby pracy procesora - przykładowa mapa pamięci
https://static.docs.arm.com/100690/0200/graphics/memory_map.png
7. Tryby pracy procesora - dla kernela
AppAppuser
OSsvc OS
... A gdzie wirtualizacja?
ARMv6
ARM SoC
8. Tryby pracy procesora - wirtualizacja
AppAppuser
OSsvc OS ... A gdzie bezpieczeństwo?
hyp Hypervisor
ARM SoC
KVM/Xen
9. Tryby pracy procesora - świat “bezpieczny”
AppAppuser
OSsvc OS
hyp Hypervisor
ARM SoC
Non-Secure Secure
Appuser
svc
mon
ARMv7
Trusted OS
Secure Firmware
10. Tryby pracy procesora - świat “bezpieczny”
AppAppEL0
OSEL1 OS
EL2 Hypervisor
ARM SoC
Non-Secure Secure
AppS-EL0
EL3
ARMv8-A
Secure Firmware
S-EL1 Trusted OS
ROM Firmware
… S-EL1?
Po co?
11. Tryby pracy procesora - ARMv8-A
1. Niezależne tryby = niezależne rejestry SP_ELx, SPSR_ELx, ELR_ELx
2. Zredukowanie kodu wykonywanego w EL3 - wprowadzenie S-EL1
3. Co z wyjątkami?
a. W pełni programowalne (przez SCR_EL3)
b. Synchroniczne - obsługa w aktualnym EL lub wyższym EL
c. Asynchroniczne (IRQ, FIQ, SError) - obsługa w aktualnym EL lub przekierowanie do EL3
4. EL3 vs SMM (Intel)
a. Kod wykonywany w EL3 - open source, licencja BSD
b. Miejsce na implementację errat hardware’owych
c. Mimo wszystko, może stać się “kontenerem na śmieci”
12. ARMv8 - zmiana trybu pracy procesora
AppAppEL0
OSEL1 OS
EL2 Hypervisor
ARM SoC
Non-Secure Secure
AppS-EL0
EL3
ARMv8-A
Secure Firmware
S-EL1 Trusted OS
ROM Firmware
smc
eret
eret
eretsvc
eret
eretsvc
eretsmc
13. Przypominajka - patrz wykład S07:E01
Kto z Was wie, co to jest BootROM?
Ważne:
ARMv8-A po przywróceniu zasilania domyślnie uruchamia się
na poziomie EL3.
BootROM
● pamięć nieulotna tylko do odczytu (EEPROM, write-protected FLASH)
● wbudowana w SoC
● znajduje się na niej kod, który jest wykonywany jako pierwszy po
uruchomieniu systemu (po podłączeniu zasilania)
● kod dostarczany przez producenta układu
14. Plan prezentacji
1. Wstęp - tryby pracy procesora
2. ARM Trusted Firmware od środka
3. Bootloadery ARM-TF
4. Secure boot w ARM-TF
5. Runtime ARM-TF a bezpieczeństwo
15. ARM Trusted Firmware
1. Referencyjna implementacja “bezpiecznego świata” dla architektury
ARMv8-A
2. Wspierane standardy:
a. SMC Calling Convention
b. Power State Coordination Interface [PSCI]
c. Trusted Board Boot Requirements [TBBR]
3. Open source, licencja BSD
a. https://github.com/ARM-software/arm-trusted-firmware
16. ARM Trusted Firmware a tryby pracy procesora
AppAppEL0
OSEL1 OS
EL2 Hypervisor
ARM SoC
Non-Secure Secure
AppS-EL0
EL3
Secure Firmware
S-EL1 Trusted OS
ROM Firmware
ARM Trusted Firmware
17. ARM Trusted Firmware - możliwości
1. Bezpieczny proces bootowania systemu (Secure Boot via TBBR)
2. Zunifikowany proces zarządzania energią w systemie (via PSCI)
3. Zunifikowany proces aktualizacji firmware
4. Niezaufane oprogramowanie nie ma bezpośredniego dostępu do
konfiguracji poszczególnych rejestrów
18. Plan prezentacji
1. Wstęp - tryby pracy procesora
2. ARM Trusted Firmware od środka
3. Bootloadery ARM-TF
4. Secure boot w ARM-TF
5. Runtime ARM-TF a bezpieczeństwo
20. Bootloadery wymagane przez ARM-TF
1. BL1
a. kod, który realizuje funkcjonalności zawarte w BootROM
b. konfiguruje DDR, ustawia rejestry kontrolne
c. ładuje BL2.
d. wykonywany na poziomie EL3, często z pamięci cache (SRAM)
2. BL2
a. minimalna inicjalizacja platformy i architektury
b. ładuje do pamięci RAM BL31/BL32/BL33
c. wykonywany na poziomie S-EL1.
3. BL31 - inaczej EL3 Runtime Firmware
a. oprogramowanie, które jest dostępne podczas działania systemu operacyjnego
b. wykonywany w EL3
c. dostępny w runtime poprzez wywołania smc
4. BL33, inaczej Non-trusted Firmware
a. UEFI/U-Boot/GRUB/OSloader
21. Minimalistyczny bootflow według ARM-TF
Na podstawie https://www.slideshare.net/linaroorg/lcu14-500-arm-trusted-firmware
Trusted World Non-Trusted World
22. Typowy bootflow według ARM-TF
Na podstawie https://www.slideshare.net/linaroorg/lcu14-500-arm-trusted-firmware
Trusted World Non-Trusted World
23. Bootflow według ARM-TF ze wsparciem SCP
https://www.slideshare.net/linaroorg/lcu14-500-arm-trusted-firmware
Trusted World Non-Trusted World
24. Plan prezentacji
1. Wstęp - tryby pracy procesora
2. ARM Trusted Firmware od środka
3. Bootloadery ARM-TF
4. Secure boot w ARM-TF
5. Runtime ARM-TF a bezpieczeństwo
25. Krótka dyskusja - pierwszy etap secure boot
Na jakim etapie projektowania systemu powinniśmy myśleć o bezpiecznym
uruchamianiu systemu?
● SoC gotowy, projektujemy architekturę software’u!
● BootROM w trakcie projektowania
● SoC w trakcie projektowania (rejestry, dodatkowe urządzenia)
26. Secure Boot w ARM-TF?
● Implementacja specyfikacji Trusted Board Boot Requirements (TBBR)
● Secure boot w ARM-TF - Trusted Board Boot
● Opisuje proces uwierzytelniania firmware od BL1 (BootROM) po BL33
● Od BL33
○ UEFI Secure Boot
○ U-Boot via Flattened Image Tree (FIT)
27. Trusted Board Boot - założenia i komponenty
Założenia:
● SHA-256 z Root Of Trust Public Key (ROTPK)
“wypalony” jednorazowo w platformie
● “nietykalność” BL1 (BootROM)
Komponenty:
● bootloadery BLx (w zależności od ilości użytych)
● certyfikaty dla każdego z BL3-x (key + content)
● dodatkowe certyfikaty dla BL2
28. CoT (Chain of Trust)
● “łańcuch” zaufania
● w ogólności, BL(x) uwierzytelnia BL(x+1)
● wykorzystuje certyfikaty kluczy oraz certyfikaty zawartości
● brak Certificate Authority (CA) przez weryfikację zawartości rozszerzeń certyfikatów
Do ustanowienia CoT potrzebujemy szeregu par kluczy:
1. Root of Trust key
2. Trusted world key
3. Non-Trusted world key
4. BL3-x key
CoT, czyli jak to naprawdę działa
29. Certyfikat klucza vs Certyfikat zawartości
Certyfikat klucza (key certificate)
1. Podpisany przez odpowiedni klucz na ścieżce CoT (RoT/TwK/NTwK)
2. Zawiera klucz publiczny do weryfikacji podpisanego certyfikatu zawartości
Certyfikat zawartości (content certificate)
1. Podpisany przez odpowiedni klucz którego część publiczna zawarta jest w
odpowiadającym mu certyfikacie klucza
2. Zawiera hash (SHA-256) danego obrazu BLx
31. Lista certyfikatów CoT (przypadek minimalny)
● BL2 content certificate - podpisany przez klucz prywatny ROT.
Zawiera SHA-256(BL2).
● Trusted key certificate - podpisany przez klucz prywatny ROT.
Zawiera klucz publiczny Trusted World oraz klucz publiczny Non-Trusted World.
● BL31 key certificate - podpisany przez klucz prywatny Trusted World.
Zawiera klucz publiczny BL31.
● BL31 content certificate - podpisany przez klucz prywatny BL31.
Zawiera SHA-256(BL31).
● BL33 key certificate - podpisany przez klucz prywatny Non-Trusted World.
Zawiera klucz publiczny BL33.
● BL33 content certificate - podpisany przez klucz prywatny BL33.
Zawiera SHA-256(BL33).
32. Rozszerzenia Trusted Board Boot
● Szyfrowanie obrazów i/lub certyfikatów
● DRAM Scrambling
○ Konieczne wsparcie kontrolera DDR
● Użycie ECDSA zamiast RSA do uwierzytelnienia
● Non-volatile counter
○ Zabezpieczenie przez atakami typu “roll-back”
33. Plan prezentacji
1. Wstęp - tryby pracy procesora
2. ARM Trusted Firmware od środka
3. Bootloadery ARM-TF
4. Secure boot w ARM-TF
5. Runtime ARM-TF a bezpieczeństwo
34. Jak od środka wygląda BL31 na przykładzie PSCI
u_register_t psci_smc_handler(uint32_t smc_fid,
u_register_t x1,
u_register_t x2,
u_register_t x3,
u_register_t x4,
void *cookie,
void *handle,
u_register_t flags)
{
(...)
switch (smc_fid) {
case PSCI_CPU_SUSPEND_AARCH64:
return psci_cpu_suspend(x1, x2, x3);
case PSCI_CPU_ON_AARCH64:
return psci_cpu_on(x1, x2, x3);
(...)
(...)
case PSCI_NODE_HW_STATE_AARCH64:
return psci_node_hw_state(x1, x2);
case PSCI_SYSTEM_SUSPEND_AARCH64:
return psci_system_suspend(x1, x2);
default:
WARN("Unimplemented PSCI Call: 0x%x n",
smc_fid);
return SMC_UNK;
}
35. Zalety ARM-TF:
● brak bootkitów
● unifikacja firmware od BootROMu
● uniwersalne standardy ARM (PSCI/TBBR)
Wady ARM-TF:
● potencjalne bugi w krytycznym dla bezpieczeństwa oprogramowaniu
● producenci firmware a BL31 - “kontener na śmieci”
Czy mamy się czego obawiać?
36. Referencje
[1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/docs -
dokumentacja ARM Trusted Firmware
[2] https://www.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13 -
“ARM Trusted Firmware for ARMv8-A”, Andrew Thoelke, ARM
[3] https://www.slideshare.net/linaroorg/trusted-firmware-deepdivev10 -
“Trusted Firmware Deep Dive” by Dan Handley, Charles Garcia-Tobin, ARM
[4]http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_
SMC_Calling_Convention.pdf - SMC
[5]http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022d/index.ht
ml - PSCI