Spørsmål:
Riktig måte å bruke TPM på for full diskkryptering
André Borie
2016-05-27 11:40:43 UTC
view on stackexchange narkive permalink

Jeg konfigurerer for øyeblikket en BitLocker-ekvivalent ved hjelp av en TPM og LUKS. Jeg har det grunnleggende riktig, og jeg er i stand til å måle oppstartsprosessen og forsegle FDE-nøkkelen ved hjelp av TPM.

Hver gang de sensitive delene (firmware, bootloader, kjerne) oppdateres, følger følgende kommando brukes til å forsegle krypteringsnøkkelen til den nye systemtilstanden: 

  tpm_sealdata -p 0 -p 1 ... -p 11 -p 13 -i <keyfile> -o <sealed keyfile>

Når systemet starter, brukes følgende til å fjerne forseglingen av nøkkelen som deretter sendes videre til LUKS for å montere det krypterte volumet: 

  tpm_unsealdata -i <sealed keyfile> -o <temporary nøkkelfil lagret i RAM>

Dette fungerer og har ønsket oppførsel - hvis oppstartsprosessen har blitt tuklet med (la oss si å legge til init = / bin / sh til kjernekommandolinjen for å omgå et root-passord) TPM nekter å fjerne forseglingen av nøkkelen, og systemet er dermed trygt.

Imidlertid har jeg noen spørsmål:

Først, TPM krever SRK-passordet hver gang en tetting / tetting utføres. Jeg vil unngå det og få det til å oppføre seg akkurat som BitLocker, som er gjennomsiktig og ikke ber om noe. Jeg har tenkt på å bruke et standard SRK-passord, men tilsynelatende er det usikkert, men svarene klarer ikke å si om en angriper som vet at passordet kan fjerne forseglingen av en nøkkel hvis PCR-ene ikke samsvarer med tilstanden de var i da nøkkelen ble forseglet.

Et annet spørsmål er hvilken vei jeg skal bruke for å forsegle nøklene - min måte innebærer tpm_sealdata / tpm_unsealdata men et annet prosjekt tpm-luks bruker tpm-nvread / tpm-nvwrite i stedet. Jeg vil gjerne vite forskjellene og om den ene veien er sikrere enn den andre.

@RickyDemer plattformkonfigurasjonsregistre.De inneholder hashes av komponenter relatert til oppstartsprosessen (fastvaren hashes MBR og setter resultatet i en PCR, i sin tur hasht bootloader kjernen og setter resultatet i neste PCR, etc) og "forsegling" data betyr TPMkrypterer data og husker tilstanden til hver PCR, og vil bare forsegle (dekryptere) dataene hvis PCR-ene er i den eksakte tilstanden som da dataene ble forseglet.Det kan være lurt å sjekke ut https://en.wikipedia.org/wiki/Trusted_Platform_Module.
Men på samme måte som å bruke standard srk-passord er usikkert, også BitLocker er uten passord.- https://blogs.mcafee.com/business/security-connected/10-things-you-dont-want-to-know-about-bitlocker/ - Selv BitLocker beste fremgangsmåter anbefaler deg å bruke TPM + pin eller TPM +usb dongle + PIN - https://technet.microsoft.com/en-us/library/dd875532%28WS.10%29.aspx - Hva er poenget med å ha noe som er "like gjennomsiktig som BitLocker", men medde samme feilene ved å bruke standard SRK-passord på Trusted Plataform-moduler?
@nwildner ja, jeg vet at Bitlocker ikke er sikker i den modusen, men jeg er villig til å akseptere risikoen for maskinvarebaserte angrep for denne spesielle saken.Det jeg spør om er imidlertid om kunnskap om SRK tillater en angriper å fjerne forseglingen av data selv om PCR-ene ikke lenger samsvarer.
Det vil ikke være mulig siden PCR-er ikke lenger samsvarer med de som ble brukt til å forsegle, selv om det å vite standard SRK-passordet, vil et smidd tilgang være umulig.Det eneste MOTBARE angrepet er den som tar sikte på MITM-kommunikasjon mellom BIOS og PCR for å nullstille PCR uten å starte maskinen på nytt for å sette systemet i "klarert" tilstand.Dette angrepet er kjent som TPM Reset Attack - http://www.cs.dartmouth.edu/~pkilab/sparks/ - AFAIK, dette er det eneste angrepet som kan sette ditt kompromitterte system i en pålitelig tilstand, og alle systemer bør væresårbar (ikke bare Linux som bruker standard SRK-pass)
En svar:
user28177
2016-06-03 22:12:43 UTC
view on stackexchange narkive permalink

Først og fremst: INGEN system er 100% trygt, men å bruke TPM er bedre enn ingen TPM i det hele tatt. TPM Chip er bare en slags kryptert lagring, som ligger på hovedkortet til datamaskiner som støtter Trusted Platform Environment, og som har BIOSer forberedt på å håndtere den.

PCR er registre med spesifikke funksjoner som håndteres gjennom TPM_Extend -operasjon. De kan ikke "settes", bare utvides (new_hash = [old_hash || new_measurement]).

TPM har Static Root of Trust for Measurements (SRTM) og Dynamic Root of Trust for Measurements (DRTM), og kombinasjonen av begge skaper et sikkert miljø. Denne fyren forklarer veldig godt hvordan dette gjøres. Det er en tillitskjede mellom faste og dynamiske gjenstander.

Tilbake til PCR-er, de er plattformuavhengige registre, og de vanligste er: 

  PCR 0 til 3 for BIOS, ROMS ... PCR 4 - MBR-informasjon og stage1PCR 8 - bootloader-informasjon stage2 part1PCR 9 - bootloader-informasjon stage2 part2PCR 12 - alle kommandolinjeargumenter fra menu.lst og de som er oppgitt i shellPCR 13 - alle filer sjekket via sjekkfilen -routinePCR 14 - alle filer som faktisk er lastet inn (f.eks. Linux-kjerne, initramfs, moduler ...) PCR 15 til 23 blir ikke brukt

Intel-baserte notatbøker bruker ofte de første 16 registerene , men det kan utvides til andre programvare / bruksområder.

Mens du skriver informasjon (forsegling) til TPM, kan du legge til en Storage Root Key (SRK) som på en eller annen måte er en "Management key" og som brukes til legg til andre nøkler til denne lagringsplassen. I henhold til manpages, vil bruk av -z sette TSS_WELL_KNOWN_SECRET (20 null byte) . 

  -z, - velkjent Bruk TSS_WELL_KNOWN_SECRET (20 null byte) som SRK-passord. Du blir ikke bedt om å oppgi SRK-passordet med dette alternativet.

Så hvis denne SRK er satt til standardhemmeligheten ( TSS_WELL_KNOWN_SECRET ), vil det ikke være nok til å angripe noen siden TPM bare kan forsegles hvis de nåværende PCR-ene samsvarer med de som brukes til å forsegle dataene. Dessuten skjer noe av PCR-håndteringen ved oppstartstid (BIOS), og det er veldig vanskelig å manipulere disse og dermed lage "falske" PCR-er. BIOS er det eneste stedet der PCR-er blir sett på som nuller før resten av prosessen finner sted.

Det eneste GRUNNLIGE angrepet er den som tar sikte på MITM-kommunikasjon mellom BIOS og PCR for å nullstille PCR uten å starte maskinen på nytt for å sette systemet i "klarert" tilstand. Dette angrepet er kjent som TPM Reset Attack.

Attacket

Så gitt alt vi har sett ovenfor, burde det være veldig vanskelig for å forfalske en klarert oppstartsprosess, så lenge BIOS tar de første målingene. Den kritiske antagelsen her er at PCR-ene ikke lett kan tilbakestilles uten å starte hele plattformen som TPM-en ligger på. Hvis en angriper er i stand til å overvåke målingene som er sendt til PCR-ene fra BIOS (med for eksempel en logisk analysator, se dette papiret), og i stand til å nullstille PCR-ene uten å starte maskinen på nytt, kan hun ta en plattform i alle konfigurasjon og sette den i en 'klarert' tilstand. Så den vanskelige delen er å få TPM til å tilbakestilles uten å få ned hele maskinen. Det er verdt å nevne at vi også har sett på mellomliggende minne og andre slike ting for å endre det løpende systemet etter at det er blitt målt, men på grunn av hastigheten på bussene som minne og harddisker sitter på, er dette en vanskelig innsats. Å angripe en tregere buss er mye lettere.

TPM-er ligger vanligvis på LPC-bussen (Low Pin Count). LPC-bussen støtter en bakkedrevet reset-linje. Dette betyr at når denne linjen på bussen kjøres til jord, skal hver enhet på denne bussen tilbakestilles. Andre enheter som er koblet til denne bussen inkluderer BIOS, og eldre tastatur- og musekontrollere. Videoen nedenfor viser at det å kjøre denne linjen virkelig er mulig, og ganske enkelt å gjøre. Vær oppmerksom på at vi i videoen får tilgang til den aktuelle datamaskinen via en ekstern ssh-økt. Dette er fordi tastaturet og musekontrolleren blir tilbakestilt når vi kjører tilbakestillingsknappen, men nettverkskortet gjør det ikke. Flere detaljer om dette angrepet (og andre!) Kan sees i min senioroppgave: A Security Assessment of Trusted Platform Modules, Dartmouth College Computer Science Technical Report TR2007-597.

Merk at dette er en forenklet versjon av ALLE TINGER som involverer Trusted Computing . Ta en titt på Architecture Document of TPMv2 for å få mer informasjon om alle operasjoner som skjer mellom bio, maskinvare og programvare under oppsettet av et pålitelig miljø.

tl; dr : Å bruke standard lagringsrotnøkkel (20 byte uten null) er ikke nok til å lage et usikkert system.

Relaterte ting:



ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...