Säkrare systemstart med Microsoft Secured Core

Och vilken kontrollfunktion byggs in i hårdvaran som inte vi användare får reda på ?

Open source löser knappast problem som berör infekterad UEFI/BIOS, vad jag förstått (och som öven nämns i artikeln) så kan ett elakt hack lägga sig så att det laddas innan själva bioset och därmed blir fullkomligt osynligt och omöjligt att bli av med.

Svårt att avgöra från Microsoft blog-inlägg som är länkat från denna artikel om detta på något sätt hindrar användning av andra OS.

Men om detta fungerar som jag tror det fungerar så ska det inte vara någon skillnad mot idag. Tar man t.ex. Ubuntu är standard-kärnan och dess moduler signerade på ett sätt så man kan använda sig av "secure boot", den delen ändras inte. Borde inte heller ändra möjligheten för användare att ställa in egna värden i UEFI.

Problemet med "chain-of-trust" är ju att man någonstans måste lita blint på något. Idag är denna punkt firmware/UEFI, vilket är ett problem då detta är programvara som kan modifieras efter systemet tillverkats, vilket i sin tur betyder att om man får in malware/virus där så är man rätt körd.

Secure-core verkar flytta punkten man litar blint på ett snäpp till och den koden stoppas in i minne som inte kan ändras i efterhand.

Om detta är rätt uppfattat blir ju fördelen att det i efterhand inte går att få in malware/virus i systemet. Den uppenbara nackdelen är att om man hittar en kritisk bugg i den koden är det bara att byta ut HW där koden lagras. Verkar trots allt som en rimlig avvägning.

Secure-core borde inte ens medföra att man är tvingad att köra med secure-boot. Secure-core är till för att säkerställa att firmware är skapat av någon som har tillgång till erforderliga kodsigneringsnycklar, borde inte finnas någon teknisk anledning att hindra använde från att välja att stänga av secure-boot (i många fall underlättar det saker som utveckling/test av kernel-modeler om secure-boot är avstängt).

Håller med att detta har potentialen att blir ett riktigt bra skydd för firmwarehack. Ser fram emot hur väl detta blir implementerat och skyddar i verkligheten.

Tills man klurar ut hur man läser av eller fejkar en nyckel.

kanske tar ett par år, men förr eller senare tippar jag på att man lyckas med det pga av någon svaghet(eller lathet hos tillverkare) i kryptot som gör att man istället för säg..128bitars säkerhet, kan förutse vissa bitar och få ner det till 32bitar och bruteforce knäcka det på en timma. Finns ju numera folk som får betalt för att göra sånt så...

Är detta jag hängde upp mig på: "Detta ämnar Microsoft att råda bot på med initiativet Secured Core, vilket är en kontrollmekanism för firmware. Istället för att förlita sig på datortillverkarnas egenutvecklade firmware samarbetar Microsoft med processortillverkare som AMD, Intel och Qualcomm för att bygga in kontrollmekanismer i processorn. Här krypteras datorns firmware med krypteringsnycklar som endast datortillverkaren har åtkomst till."

Menar de något annat än UEFI när de skriver Firmware menar du?

Inte supertydligt, men låter ju lite som att det kommer bråka en del med skärddarsydda UEFI, jag har dock inte koll nog på hur UEFI för att avgöra själv och de är inte precis kristallklara i sin beskrivning:

"System Guard uses the Dynamic Root of Trust for Measurement (DRTM) capabilities that are built into the latest silicon from AMD, Intel, and Qualcomm to enable the system to leverage firmware to start the hardware and then shortly after re-initialize the system into a trusted state by using the OS boot loader and processor capabilities to send the system down a well-known and verifiable code path."

Jag reagerade mer på de inblandade aktörerna: Microsoft, baserade i washington, samarbetar med AMD, Intel och Qualcomm, alla tre baserade i kalifornien. Inte precis en intressegrupp som representerar hela världen.

Så om tillit hamnar i denna kryptering över något annat så räcker det att någon av dem (helst microsoft) är villiga att samarbeta med något av landets statliga organ vid något tillfällen för att de ska få obekvämt mycket insikt i vad som kan göras för att kringgå det hela, vilket inte vore något nytt, och sedan att någon idiot tar med sig jobbet hem och plötsligt har du en ny eternalblue kris (wannacry, petya).

Sedan finns det inget som på ytan tyder att NSA/EquationGroup fick hjälp av microsoft med Eternalblue, snarare tvärtom.
Men bra att veta att förhoppningsvis kommer framtidens säkerhetsfails åtminstone gå igenom NSA och dylikt först innan random ransomware-crews i kina och ryssland får tag i dem

Ja det är väldigt luddigt-

Men ett moddat UEFI är ju per definition en "säkererhetsrisk". Jag litar på att 1usmus är reko och inte lägger in fulkod i sina mods, men gör Microsoft det? Och kan man vara säker på att filen man laddar ner verkligen är den som anges osv? Det går ju inte rimligtvis begära att de ska ha koll på och vitlista alla mods, så förhoppningsvis så går funktionen stänga av istället.

Ja det som blir intressant är ju just hur detta ska hanteras i de fall där det som ska bootas definitivt inte använder sig av dessa nya funktioner- precis som secure boot brukar ryka direkt när man ska börja använda *nix av något slag så gissar jag att detta snabbt kommer bli den första grejen många entusiaster stänger av. När jag köper en ny dator brukar en ren windows-installation vara det första jag gör, och om jag ändå gör det och denna feature betyder att jag i framtiden kommer behöva hoppa in i bios för och efter varje gång jag vill ha dualboot/boota en livecd/boota en dos-sticka eller vad som helst annat så blir det ju inte optimalt.

MEN, för datorer i företags/skolmiljö så kan jag tänka mig att det är ytterligare ett steg i rätt riktning, kanske.