Jeg har netop modtaget endnu en god nyhed for thoriumenergi i Danmark. Jeg har fået mulighed for at tale om thoriumenergi og Copenhagen Atomics på TEDxCopenhagen 7. april.
Denne blog er anden del i en serie om kontrolsystemer. I første del fik vi forklaret, hvad walk-away-safe- og priminister-safety-principperne går ud på. Copenhagen Atomics ønsker at overholde begge disse sikkerheds- principper. Men vi vil gerne endnu videre:
Der findes en række systemer i verden, hvor der er brugt for MEGET sikker computer/software. Nogle af dem er:
Jeg har været så heldig at være involveret i flere projekter med software til nogle af de ovenstående, og det blev meget hurtigt klart for os, at det er meget langt fra optimalt at bruge de gængse operativsystemer, vi har i verden i dag. Det ville være formålstjenligt, hvis vi kunne skabe et helt nyt VERY SECURE OPERATING SYSTEM (VSOS), som kan bruges af alle ingeniører til applikationer som de ovenstående. De 5 primære egenskaber skal være:
De, som ved noget om software og hardware, kan se, at dette bliver SVÆRT! Målet er heller ikke 100.0000 % fejlfri, men 99.999999% fejlfri. Så det handler om at minimere fejl til næsten ingen. Lad os starte ved punkt 1. Hvis hardware og software ikke må kunne gå ned, så skal hardwaren dubleres en eller flere gange, og den skal være godkendt via meget grundige tests til det driftsmiljø, som den udsættes for. Softwaren skal laves, så den ikke kan lave deadlock og den skal kunne tåle memory- og CPU-fejl. Desuden skal den være så simpel, at det er nemt at forstå, hvad den laver. Dette gøres bedst ved at lave softwaren som en state-maskine på det øverste niveau og have en række hardware watchdog timers som sikker genetablering, hvis noget er gået galt.
Hvis noget ikke skal kunne hackes, skal vi sikre os, at der er meget begrænset skriveadgang til systemet, samt at det kræver adgang til flere nøgler, før man kan opdatere systemet. Som hovedregel må skriveadgang til systemet ikke kunne ændre layout og regler for state maskinen på det øverste niveau. Det må kun være data, som kan bruges af subrutiner i de underliggende niveauer af systemet. Skriveadgang kan altså godt igangsætte state change, på topniveau, men ikke ændre selve state maskinen. Hvis dette princip overholdes, bliver det MEGET svært for en hacker at få kontrol med systemet. Skriveadgang skal f.eks. bruges til at fortælle en drone, hvor den skal flyve hen eller fortælle et atomkraftværk, hvor meget power output man ønsker den næste time.
Der er kun ét stort hul tilbage, nemlig at hackeren kommer ind via en software update. Men samtidig vil vi gerne have at det er muligt at lave opdatering af software af vores kirurgiske implantater og selvkørende biler, efterhånden som teknologien bliver forbedret. Så hvordan sikrer vi os lige, at en hacker ikke får puttet noget kode med ind i en af disse opdateringer eller bare snyder vores VSOS til at tro at hans opdatering er en officiel handling og dermed få den kørt på.
Dette punkt kræver nok lidt mere debat og dialog, men et af de forslag vi er kommet frem med er, at før man kan lave en software opdatering, skal den nye kode altid uploades via VPN fra 2 forskellige adresser, som man har tillid til. Når systemet har modtaget 2 pakker, som er ens, så giver VSOS besked til fabrikanten og evt. andre ”myndigheder” om, at den vil opdatere om 24 timer. Grunden til at vi ønsker, der skal gå 24 timer før opdateringen bliver installeret, er for at give tid til at opdage, hvis noget er galt og sende en update abort command. Samtidig lægger dette også et pres på dem, som laver en officiel software opdatering, så de ikke er uforsigtige og frigiver noget skidt. Der går altså 24 timer, før de kan overskrive forrige opdatering. Grunden til, at det skal være open source, er for at skabe maximal tillid til systemet. Måske starter vi kun med 99.999% fejlfri på første version, men vi skulle gerne nå meget højere op. Dette gøres bedst igennem åbenhed og input fra et stort antal mennesker = open source.
Som omtalt i første del af denne artikel, så vil vi gerne have en stor grad af læseadgang til kontrolsystemet, hvis det bruges til at styre et atomkraftværk. Dette gælder også hvis det er et kirurgisk implantat med bloddata eller en quadcopter med positionsdata. Men det er selvfølgelig vigtigt at læseadgangen altid er sekundær til afvikling af den styrekode, som lever inde i kontrolsystemet, og læsesystemet må ikke åbne for yderligere huller, som hackere kan bruge. Derfor skal man altid tænke på læseystemet, som om det allerede er blevet hacket.
Ovenstående figur viser tydeligt at Read controllerne kører på hardware, som er helt adskilt fra den centrale kontrolenhed (CCU). I dag hvor en CPU med hukommelse og internetadgang kan fås til $5 eller kan laves, så den fylder mindre end 1 mm2, så ville det være helt forkert at designe dem på samme hardware.
CCU’en skal være dupleret, så man kan lave software opdatering og teste, at den nye software virker, før man skifter over. Den skal selvfølgelig også kunne tåle, at strømmen forsvinder midt under software opdateringen. Samtidig giver en duplering også mulighed for at overleve i nogle uger fra, at den ene enhed fejler, til man får skaffet og skiftet til nyt hardware. Figuren viser også, at det er CCU’en, som styrer al kommunikation imellem Read controlleren og det øvrige system. Der sker ingen eller næsten ingen dataflow fra Read controlleren og ned til CCU’en, højst nogle få flag eller enkelte talværdier for at undgå sikkerhedshuller.
Det er tanken, at hardware design og software i Read controlleren og CCU’en er open source og tilgængelig fra github. Mens de, som hedder ”other systems”, i princippet godt kan være proprietære systemer, kunne de f.eks. køre under en anden proces og evt. med meget færre rettigheder. F.eks. uden mulighed for at lave software opdateringer. Disse detaljer er endnu ikke færdig debatterede.
Vores system kræver selvfølgelig noget specielfremstillet hardware, som gør det væsentligt dyrere end det, vi finder i konsumerelektronikindustrien. Men det vil stadig være meget billigere end alt det specielle hardware, man finder i kontrolrum i traditionelle atomkraftværker.
Copenhagen Atomics er p.t. i dialog med nogle meget dygtige softwarefolk om udviklingen af dette VERY SECURE OPERATING SYSTEM.
Planen er at gøre designet mere færdigt og samtidig begynde at implementere det. Dernæst vil vi lave en officiel Request for Comments (RfC), som skal indsendes til IETF eller en anden relevant organisation. Dette må forventes at give anledning til noget feedback og nogle rettelser, hvorefter det er tid til at lave den første MVP (Minimum Viable Product) til test og frigivelse på Github. Næste skridt derefter ville nok være artikler i akademiske tidskrifter eller præsentation på konferencer.
Vi vil dog fortsat gerne i kontakt med personer med unikke kompetencer inden for dette felt (OS / hardware / test / sikkerhed), som kan hjælpe os med at lave verdens mest sikre OS-platform.
Som en del af ovenstående så vil vi også implementere kontrolsystemet til Copenhagen Atomics Waste Burner, så vi kan se, at det virker i praksis. Det skulle gerne være klar om ca. 2 år, når vi forventer at have vores første none-fission prototype klar. Selve operativsystemet bliver ikke særlig kompliceret, men der bliver dele af de underliggende systemer, som har godt med kød på sig. Det er dem, som er betegnet som ”other systems” på figuren ovenfor. Senere vil der også komme en blog om nogle af disse dele, men jeg vil her blot give en meget kort forklaring på, hvordan denne del kommer til at virke.
Internt i kontrolsystemet har vi en vektor med over 1000 parametre. I mange af disse parametre er temperatur og tryk forskellige steder i vores reaktor, men mange af parametrene viser også mængden af de forskellige isotoper i vores fuel- og off gassystem. Når man har styr på disse isotoper, så har man nemlig også styr på, hvor meget varme og stråling, der udvikles, og hvor meget fri fluor der er i systeme, og det er meget vigtigt for en optimal og sikker drift.
Hvis denne vektor kommer uden for et på forhånd veldefineret sikkert driftsområde, så vil det omgående give anledning til, at kontrolsystemet skifter til et shutdown state, og reaktoren lukker ned. Umiddelbart vil der formentlig være mindst følgende 10 states på det øverste kontrolniveau i CCU’en:
Formentlig vil det også være muligt at læse den lange vektor med over 1000 værdier fra Read controlleren mindst en gang i minuttet. Nogle af tallene måske endnu oftere. Stopknappen, som vi omtalte i del 1 af denne
Kommentarer (13)