Kategoriarkiv: Inbyggda system

Bra samling av bithanteringstrick

Vid konstruktion av digitala tekniska lösningar är det inte ovanligt att man behöver göra olika bitmanipulationer och trick med bitar. Detta gäller inte minst inbyggda system med begränsningar i utrymme och prestanda. Alla erfarna konstruktörer har några favorittrix dom tar till för att effektivt lösa ett problem. Typiska trick är kopiering av data i internregister, hitta mest signifikanta biten som är satt i ett ord eller beräkna paritet.

Sidan Bit Twiddling Hacks har den största samlingen av bithanteringstricks jag sett. Det som gör trixen speciellt intressanta är att i stort sett samtliga tricks formellt verifierats med verktyget UCLID. De flesta trick är mest effektiva på en processor med 32-bitars operatorer (och fungerar ofta bra på mindre arkitekturer). Men vissa av dom är avsedda för maskiner med 64-bitars operatorer eller generellt oavsett bitstorlek.

Jag hittade ett bra trick för att beräkna rank parallellt som i hårdvara fungerade riktigt bra. Du kanske också hittar något matnyttigt?

Rita vågformer med Wavedrom

Vid dokumentation av digitala hårdvarukonstruktioner är vågformsdiagram ofta det bästa sättet att förklara timingberoenden och hur protokoll beter sig på cykelnivå. Ett exempel är den här figuren som visar hur en A/D-omvandlare arbetar:

Timingdiagram för A/D-omvandlare.
Timingdiagram för A/D-omvandlare.

Som konstruktör kan det vara svårt att smidigt skapa bra vågformsdiagram att inkludera i dokumentation. En skärmdump från en vågformsvisare som visar testat beteende ökar sannolikheten att diagrammet stämmer med hur konstruktionen fungerar. Samtidigt kan en skärmdump visa för mycket irrelevant information och även bli svårläst vid utskrift etc. Vilka av följande signaler är relevanta att visa för att entydigt förklara funktionen?

GTKwave med en lite mer komplex vågformsdump.
GTKwave med en lite mer komplex vågformsdump.

Man kan alltid rita med olika verktyg. Jag har genom åren använt ett otal ritprogram som Visio, Star/Open/Libre Office Draw, Excel, yED (ett fantastiskt grafverktyg för övrigt) etc. Detta fungerar och kan ge figurer som skalar snyggt och blir bra vid utskrift. Men det är knappast smidigt och effektivt att rita diagram i rena ritverktyg. En variant av att rita diagrammen för hand är att använda ASCII-grafik.

Sedan finns det flera verktyg som går att använda specifikt för att skapa timingdiagram. TimimgTool är ett sådant verktyg som dessutom kan generera en testbänk för konstruktionen utifrån diagrammet (dvs diagrammet kommer först och är sättet du som konstruktör får beskriva din konstruktion). Ett annat liknande verktyg är TimeGen. Slutligen finns det tillägg/makron för att skapa timingdiagram till typsättningsspråket/systemet TeX. Figurerna som genereras ser jättefina ut, men bieffekten är att man måste använda hårbollen TeX…

Timingdiagram genererat med TeX
Timingdiagram genererat med TeX

Sedan ett tag har Google ett kul, fritt (MIT-licensierat) projekt kallat Wavedrom som i mångt och mycket gör det jag vill kunna göra med timimgdiagram. Utifrån en JSON-beskrivning kan Wavedrom generera diagram i form av SVG-bilder. Fördelen med detta är att det går relativt enkelt att, antingen manuellt i en texteditor, eller verktygsmässigt generera JSON-underlaget för diagrammet. Och eftersom utdata är i SVG-format är det lätt att lyfta in i olika textbehandlare och få figurer som skalar bra och ser snygga ut.

Exempel på diagram med Wavedrom.
Exempel på diagram med Wavedrom.

Wavedrom är byggt med Javascript och HTML5 och det är enkelt lägga in Wavedrom-diagram till en webbsida. Det finns även ett tillägg till Chrome som gör att du kan editera Wavedrom direkt i webbläsaren. Så här ser det ut när jag testar med ett exempel:

Test av Wavedrom i Chrome.
Test av Wavedrom i Chrome.

Om du i ditt jobb sitter och ritar timingdiagram och vill hitta mer effektiva sätt att skapa fungerande snygga diagram hoppas jag att du här hittar några bra alternativ – mitt förslag är att testa Wavedrom.

Knäckta satellitkrypton och hemliga algoritmer

Ars Technica skriver om hur forskare i Tyskland lyckats knäcka krypton som används vid satellitkommunikation.

Satellitkommunikation

Eftersom signalen från en satellit täcker så stora ytor är det enkelt att fånga in signalen. För att skydda samtal från avlyssning krävs därför ett bra konfidentialitetsskydd – ett bra krypto.

Det är den internationella standardriseringsorganisationen ETSI som specificerat både kryptona GMR-1 och GMR-2 kryptona samt hur dom ska användas. Hur dom ska användas är öppen information, men själva kryptona är hemliga. ETSI skriver i sin specifikation (pdf):

The internal specification of algorithm A5-GMR-1 is managed under the responsibility of the GSC; it will be made available in response to an appropriate request

Att algoritmerna är hemliga hindrade dock inte forskarna. Genom hacka sönder uppdateringsfiler av programvaran till telefoner samt genom att analysera trafiken vid användande av satellittelefoner från Thuraya och Inmarsat kunde forskarna räkna ut hur algoritmerna fungerar.

Forskarnas analys visar att det skydd kryptona ger är så svagt att det finns en klar risk att satellitbaserad trafik inklusive samtal går att avlyssna. I artikeln Don’t Trust Satellite Phones: A Security Analysis of Two Satphone Standards skriver forskarna:

In this paper, we analyze the encryption systems used in the two existing (and competing) satphone standards, GMR-1 and GMR-2.

We were able to adopt known A5/2 ciphertext-only attacks to the GMR-1 algorithm with an average case complexity of 2**32 steps. With respect to the GMR-2 cipher, we developed a new attack which is powerful in a known-plaintext setting. In this situation, the encryption key for one session, i.e., one phone call, can be ecovered with approximately 50–65 bytes of key stream and a moderate computational complexity.

A major finding of our work is that the stream ciphers of the two existing satellite phone systems are considerably weaker than what is state-of-the-art in symmetric cryptography.

(På forskarnas egna webbplats finns mycket mer information.)

Forskarnas bedömning är att eftersom det skulle kosta så mycket att byta algoritmer kommer dessa inte att ändras. Istället rekommendrar dom att betrakta kommunikationen som öppen och sedan komplettera med ytterligare lager av skydd. Tyvärr kostar dessa extraskydd kapacitet i en förbindelse som redan har ganska begränsad kapacitet. Dessutom kan dessa skydd införa ökad fördröjning och andra trafikala problem. Inmarsat, som även är operatör av satellitkommuninkation har över än så länge inte kommenterat eller gett några officiella råd till sina kunder.

Tyvärr är detta inte första gången ett hemligt krypto visat sig vara svagt och långt ifrån vad man kan förvänta sig av ett krypto som används i befintliga system. I smarta kort av MiFare Classic-typ, som bland annat används för betalning i publika transportsystem i Göteborg och Stockholm, finns ett hemligt krypto kallat Crypto-1. Trots att kryptot var hemligt lyckades forskare klura ut både hur kryptot fungerar, och att dess säkerhet var i stort noll.

Keeloq är ett krypto som används i elektroniska bilnycklar av i stort sett samtliga stora biltillverkare. Även detta krypto var hemligt och även här lyckades forskare räkna ut hur det fungerar samt visa på kryptots monumentala brister.

För ETSI är forskarnas nya resultat ännu ett misslyckande. Deras kryptostandarder för DECT, GSM, 3G och satellitkommunikation har alla visat sig ha stora brister. När det kommer till kryptoalgoritmer är det frågan om ETSI lever upp till sin devis World Class Standards.

Att hålla informationen om vilka kryptografiska algoritmer du använder hemliga är inte ett problem. Du kan helt enkelt strunta att berätta det. Problemet är om säkerheten hos ditt system beror av att denna information är hemlig.

Information som om den kommer ut kan skada din verksamhet ställer krav på skydd som kostar pengar. Du behöver införa mekanismer och metoder för att begränsa tillgången. Skyddet behöver dessutom övervakas så att du vet att det faktiskt fungerar.

Dessutom bör du ta fram en plan för hur du ska agera om informationen trots allt kommer ut. När hemligheten kommit ut måste den troligen bytas ut, alternativt att du måste kasta in handduken och införa andra skyddsåtgärder så som forskarna nu föreslår att användare av satellitkommunikation bör göra. Att byta algoritm kan bli väldigt kostsamt. Är det en algoritm som används i inbyggda system som tillverkas i stora volymer, används i fält och har lång livslängd är innebär bytet eventuellt att du måste byta ut hela systemet.

Hade din hemlighet istället bara varit en kryptonyckel hade bytet troligen handlat om att byta ut en sträng på 16, 32, 64 tecken eller liknande. Säkerheten sitter i nyckeln. Den är allt du egentligen ska behöva skydda.

Bra kryptoalgoritmer försvagas inte av att informationen om hur dom fungerar är känd. Tvärt om beror vår tillit på algoritmerna just av öppenheten. Algoritmen som utgör blockkryptot AES undersöktes ett stort antal gånger på olika sätt innan den accepterades som standard. Och AES fortstt under kontinuerlig undersökning. Det finns generationer av forskare som fixat sin hatt eller årets publiceringar genom att försöka hitta på nya sätt att vara elak mot AES.

Ju fler undersökningar som en algoritm står emot desto större tillit vågar vi sätta till den. Och det är öppenheten, tillgängligheten som gör dessa undersökningar möjliga.

I jämförelse med en öppen algoritm undersöks en hemlig algoritm mer sällan. Dessutom sker undersökningen oftast under en begränsad tid. När en hemlig algoritm bedömts som säker tas den i bruk och sedan sker sällan omvärdering av algoritmens säkerhet.

Det finns användare av hemliga algoritmer som vet vad dom gör, som har den spetskompetens som krävs att göra en bra bedömning. Men när erkända kryptoforskare som medlemmarna i ETSIs säkerhetsgrupp SAGE gör fel och försvagar snarare än förstärker en algoritm (som är fallet med KASUMI, byggt på MISTY-1) är det inte självklart att även en enskild grupp med aldrig så skarpa experter gör en bra bedömning. Den mekanism som har störst chans att ge bra algoritmer är öppna processer med många, oberoende tester över lång tid. Att skynda långsamt och kontinuerligt ompröva resultat.

AES togs fram genom en sådan process, strömkryptona i eSTREAM togs fram genom en sådan process och kommande hashfunktionen SHA-3 tas fram på detta sätt. Det finns inga garantier att detta ger säkra algoritmer, det visar bland annat eSTREAM där några krypton i dag är knäckta. Men detta är den bästa metod vi har i dag och det är en process som förbättras för varje iteration.

Även ETSI verkar till slut ha lärt sig av alla sina misstag och i arbetet med den senaste standarden ZUC har det faktiskt organiserats seminarier, workshops, diskussionsforum på nätet och varit en mycket mer öppen process (även om det finns mindre öppna designval även i ZUC).

Om du oroar dig för att någon ska veta hur ditt system fungerar så strunta att berätta vilket krypto du använder. Men hitta inte på egna algoritmer, utan använd öppna, etablerade standarder som stått emot granskning under lång tid. Gör du det är nyckeln till kostnadseffektiv,fungerande säkerhet din kryptonyckel.

10000 industriella kontrollsystem kopplade till Internet

Ett argument som ofta framförs när det gäller säkerhet för industriella kontrollsystem (på engelska ofta kallade ICS och SCADA) är att det inte finns några riktiga problem, detta för att systemen är isolerade och inte är kopplade till externa nätverk – exempelvis till Internet. Populära isolerande skyddmetoder är så kallade luftgap (på engelska air gap) samt datadioder. Med luftgap avses att det inte finns någon elektrisk förbindelse mellan kontrollsystemets nätverk och andra nätverk. Med datadioder avses mekanismer som gör att  trafiken i nätverket bara kan flöda åt ett håll.

Datadiod

Figuren visar hur en datadiod är tänkt att figuren. Notera att figuren egentligen är åt fel håll. Detta för att datadioder används för att isolera system som hanterar känslig information och där vill man inte att information ska läcka ut. I ett kontrollsystem är det oftast precis tvärt om som är intressant. Det går att skicka över mätdata från kontrollsystemet, men det går inte att skicka styrkommandon till kontrollsystemet. Leverantörer av industriella säkerhetssystem kräver ofta att deras utrustning ska skyddas genom isolering. Men hur fungerar det i verkligheten, och är detta egentligen bra och robusta metoder att hantera säkerhetsproblem?

Wireds säkerhetsblogg Threat Level rapporterar om resultat som säkerhetsforskaren Eireann P. Leverett nyligen presenterade som visar att det finns industriella kontrollsystem kopplade till Internet, mer exakt har Leverett hittat fler än 10000 stycken! Genom att använda nätverksscannern Shodan har Leverett letat efter kända industriella ontrollsystem, och även kunnat identifiera vilka versioner av system som används. Leverett har sedan mappat dessa i en fin graf över världen som visar var systemet finns:

Everetts graf som visar var olika industriella kontrollsystem finns och deras svagheter.
ICS med versioner och dess svagheter.

Av de system Everett hittade visade sig bara 17% över huvud taget använda någon form av enklare accesskontroll, exempelvis lösenord! Undersökningen är en del av den avhandling Everett arbetat med och för den som vill veta mer om Everetts undersökning finns hans avhandling Quantitatively Assessing and Visualising Industrial System Attack Surfaces hos Wired.

Jag anser att resultaten Everett presenterat visar att bara använda isolering som enda säkerhetsmetod för sitt industriella kontrollsystem inte ger ett adekvat skydd. I stora, komplexa kontrollsystem med tusentals mät- och styrnoder finns det stor risk att effektivisering, krav på snabb problemlösning, underhåll utfört av tredje part eller misstag leder till att hela eller delar av systemet kan exponeras mot omvärlden under kortare eller längre tid. Någon kopplar in ett GSM-router för att kunna övervaka en nod som sitter taskigt till rent fysiskt. En leverantör behöver möjlighet att få diagnostik. En del av systemet kopplas temporärt in på kontorsnätet. I dag är det inte heller nyfikna personer som sitter och för hand letar efter märkliga maskiner på Internet. Istället är det robotar, automatiska scannerverktyg som Shodan som periodiskt scannar av Internet. Risken att det exponerade systemet blir upptäckt är därför mycket större än man kanske tror.

Istället bör man räkna med att sitt industriella kontrollsystem kommer att kunna exponeras på olika sätt och börja ställa krav på säkerheten hos de noder och maskiner som är inkopplade i nätet. Att använda isolering är bra, men det bör kompletteras med säkerhet på djupet. Och om det nu finns kommunikationskanaler ut ska dom självklart använda vettiga autenticeringsmekanismer. Att 87% av de system Everett hittade inte ens har lösenordsskydd är väldigt skrämmande.

För den som ändå tror på isolering som fungerande metod bör studera Stuxnet-attacken. Där var kontrollsystemet isolerat. Men det som inträffade var att någon, avsiktligt eller oavsiktligt kopplade in ett USB-minne eller laptop och därmed infekterade systemen innanför luftgapet. Att tekniker tar med sig mätverktyg, laptops när dom ska lösa problem och kopplar in dessa i systemet borde knappast vara otänkbart scenario. Självklart ska det ställas krav på utrustningen som kopplas in, exempelvis uppdaterat virusskydd, men säkerheten måste även finnas inne i kontrollsystemet.

Workshop om lättviktskrypton

Det finns i dag en stark trend mot att allt fler saker runt omkring oss kopplas upp till Internet – Dörrar, kylskåp, båtmotorer, dunjackor, värmeväxlare, plankor på byggvaruhuset, glödlampor, termostater, kranar etc. Allt annat än fräcka och och sexiga saker – men viktiga för att vårt samhälle ska funger och med stor potential till effektivisering när sakerna får digital intelligens och kan börja kommunicera.

För att detta Internet of Things (IoT) ska fungera måste vi kunna säkert identifiera sakerna och utbyta information – kommandon och status med dessa saker. I vissa fall krävs även att kommunikationen är hemlig för alla utom de som har rätt att kommunicera med en given sak – men det är inte lika viktigt. Detta ställer krav på att det finns säkerhetsmekanismer i IoT-sakerna. (Jag har tidigare skrivit om behovet av säkerhetsmekanismer anpassade för IoT). ECRYPT II-Workshopen ECRYPT Workshop on Lightweight Cryptography som anordnades i slutet av november med målsättningen att presentera nya säkerhetslösningar för små, inbyggda system är därför klart relevant och intressant.

Att döma av programmet (pdf) sker det aktiv utveckling av både kompakta symmetriska krypton och hashfunktioner. Oftast är det hårdvaruimplementationer där man mäter antalet grindar (generaliserad till antalet NAND2-grindar) och energiförbrukningen. Ett exempel är blockkryptot Piccolo-128 som bara kräver 60% av storleken hos den minsta implementation av AES-128 som tidigare presenterats. Dock med en prestanda på 40% av AES.

Det jag tycker är mer intressant är presentationen av resultaten från implementationer av 12 standardkrypton (IDEA, DES, AES, KASUMI, TEA m.fl.) på Atmels ATtiny45-processor. Detta är en minimal (även fysiskt) 8-bitars processor med 4 kByte FLASH-minne, 256 Byte EEPROM och 256 Byte SRAM. Det finns inte mycket detaljer om hur implementationerna är uppbyggda, men att döma av det som presenterades lyckades dom implementera alla 12 algoritmer.

Atmel ATtiny45.
En näve ATmel ATtiny45-kretsar.

Et annat arbete som presenterades är försök att implementera autenticerande kryptomoderTexas Instruments processor MSP430. De moder man arbetat med är CCM, GCM, SGCM, OCB3 och Hummingbird-2. Detta är ett i mina tycken klart intressant. Att få konfidentialitet och autenticering samtidigt ger en mer kompakt lösning än separata algoritmer.

Det presenterades även förslag till autenticerat broadcast-protokoll för industribussen CAN samt försök att implementera AES på en 4-bitarsprocessor(!).

Det jag däremot saknar är nya, lättviktiga asymmetriska algoritmer samt försök att befintliga asymmetriska algoritmer. Det spelar ingen roll om vi har högar med blockkrypton anpassade för små processorer om vi inte kan göra bra nyckelutbyten. En bra minimal implementation av ett vältestat krypto som AES (gärna som stödfunktion i processorns hårdvara), en autenticerande kryptomod samt en nyckelutbyte är mycket mer intressant än ännu ett blockkrypto eller hashfunktion.

För den som vill läsa de artiklar som presenterades finns dom samlade i proceedings för konferensen och går att ladda ner (pdf).

En sista sak. ECRYPT II har även en webbplats, ECRYPT Lightweight Cryptography Lounge där information om kryptolösningar för kompakta, begränsade samlas. Är du intresserad så ta en titt där – det gör jag.

OpenCL för FPGA-konstruktion

Uppdaterat med referens till artikel om OpenCL från Altera.

En ny version av OpenCL

För ett par veckor sedan släppte organisationen Khronos version 1.2 av OpenCL. OpenCL är en utökning av programspråket C99 samt ett ramverk med verktyg och bibliotek. Med OpenCL är det möjligt att bygga program som utnyttjar parallell beräkningskapacitet i processorer (CPU), grafikprocessorer (GPU) m.m. Inte minst viktigt är att OpenCL gör det möjligt att programmera heterogena system, dvs system där det finns olika typer av processorelement.

Kärnan i OpenCL är möjligheten att skapa segment kallade kernels av kod och data koden skall bearbeta. Det är upp till dig som programmerare att beskriva hur de parallella operationerna ska utföras, vilka dimensioner problemet ska ha etc. När väl din kernel är skapad och kompileras genereras kod som körs på den parallella hårdvaran samt sekventiell kontrollkod avsedd för en kontrollprocessor. Kontrollkoden ser till att skicka kernel och data till den parallella hårdvaran, får kernel exekverad och tar slutligen emot resultatet.

Den vanligaste användningen av OpenCL är för att programmera GPU:er i datorer. OpenCL börjar även användas för att programmera den ökande mängden processorkärnorna i vanliga processorer, nätverksprocessorer och digitala signalbehandlingsprocessorer (DSP). Inte minst är detta intressant i högpresterande inbyggda system som basstationer för mobilsystem.

För den som vill titta närmare på OpenCL 1.2 finns specifikationen här (pdf).

Sponsorer av OpenCL är företag som Apple, AMD, Intel och IBM, men även Ericsson stödjer Khronos och OpenCL.

En ny version av OpenCL är egentligen inte så intressant. Det som fick mig att reagera på EE Times artikel var istället att företaget Altera officellt börjat stödja OpenCL. Altera tillverkar inte processorer – hårdvara som har en fix instruktionsuppsättning man kompilerar sin kod till. Altera bygger FPGA:er.

Sidospår om FPGA-konstruktion

En FPGA är en digital krets fylld med små byggblock, ledningar och kopplingselement. Hur byggblocken fungerar och hur dom kopplas samman via ledningar och kopplingselementen styrs av bitar lagrade i kontrollregister. Genom att skriva ner en konfiguration i kontrollregistren går det att få FPGA:n att implementera olika digitala funktioner. Gränssnitt för Ethernet, MP3-avkodare, filter för bildbehandling och faktiskt hela processorer och digitala system går att implementera i en modern FPGA. Man kan till och med implementera en FPGA i en FPGA.

Poängen med en FPGA är att den är väldigt parallell med massor av små byggblock, men det finns ingen egentlig instruktionsuppsättning eller schemaläggare som styr hur exekveringen går till. Det är en ren digital struktur och det är upp till dig som användare att skapa den konfiguration du behöver. Detta arbete är mer likt traditionell digital konstruktion än att programmera en processor, även om du använder assembler.

Normalt används konstruktionsspråk som Verilog, SystemVerilog (SV) eller VHDL. Den generella abstraktionsnivån i dessa konstruktionsspråk är relativt låg. Så länge som jag arbetat med digital konstruktion (sedan mitten av 1990-talet) har det dock funnits en strävan, en trend mot att försöka lyfta abstraktionsnivån.

Det har kommit och gått en massa försök med högnivåsyntes till nya språk som SystemC. En i min åsikt gemensam egenskap med dessa lösningar har varit en stor komplexitet och oförmåga att leva upp till de produktivitetsökningar man utlovar. Genom att gräva ner sig i schemaläggningar, delning av resurser, optimeringar etc har verktygen blivit komplexa, svåra att arbeta med och kräver mycket datorresurser.

Altera C2H

En som tog en liten annan väg var faktiskt Altera som för några år sedan lanserade C2H. C2H är ett verktyg för att ta vanlig C-kod och konvertera till digital hårdvara. Och det som gör C2H så smart, var att de är så dum.

Du som konstruktör får hela ansvaret att skriva din C-kod så att C2H kan fatta hur motsvarande hårdvara ser ut. Använder du 17 multiplikationer i din funktion får du 17 multiplikatorer. Vill du använda färre multiplikationer får du skriva om din kod så att samma multiplikationsuttryck används flera gånger.

Å andra sidan är C2H snabb. På några minuter kan du generera hårdvara och få återmatning. Eftersom C2H även är en del av utvecklingsverktygen för Alteras processor Nios II kan du dessutom testa att köra koden som ren SW, profilera din kod och sedan försöka konvertera de kritiska funktionerna till hårdvara.

Den magi som finns i C2H är kopplingen mellan hårdvaran och den kontrollkod som skapas för Nios II-processorn som krävs för att styra den genererade hårdvaran och använda den i resten av applikationen.

För den som vill veta mer finns det utbildningsmaterial och användarguide för C2H. Det finns även ett exempel på acceleration av beräkning av Mandelbrotmängder. Den arkitektur som används ser ut så här:

Arkitekturen hos Alteras Mandelbrotsberäknare.

I exemplet nås 60 gångers prestanda jämfört med en ren SW-implementation.

Acceleratorn blir alltså en applikationsspecifik stödprocessor till processorn. Men det går att bygga coprocessorer som är kapabla att själva läsa och skriva till minnen och arbeta självständigt.

FPGA – den nya OpenCL-arkitekturen

När jag tittar igenom det material från Altera som finns om OpenCL får jag samma känsla som när jag såg C2H första gången.

Du som konstruktör får ansvaret för att styra vad som ska bli parallell hårdvara och att det data som skall bearbetas finns i rätt format etc. Och kanske det viktigaste – att försöka parallellisera de delar som spelar roll för applikationen. Den magi, infrastruktur får att få systemet att hänga ihop sköter Altera och OpenCL.

Att ha FPGA som målplattform för OpenCL öppnar upp för nya typer av heterogena arkitekturer med mulicore, GPU och FPGA:er blandat. En FPGA kommer aldrig att komma upp i de klockfeekvenser som en GPU snurrar i så för vissa applikationer kommer en FPGA inte att ersätta CPU eller GPU.

(En tumregel att en FPGA når en tiondel av klockfrekvensen som en direktimplementerad digital krets. Den funktion som implementeras kräver dessutom ungefär tio gånger så mycket digitala grindar i en FPGA.)

Fördelen med FPGA:n är istället att den är en generisk digital struktur med mängder av “processorelement”. Antalet element och hur elementen fungerar kan direkt anpassas (skapas) för att processa en OpenCL-kernel. Detta gör att du kan få mycket högre prestanda i en mer flexibel arkitektur. Och precis som med C2H kan du med OpenCL alltid pröva, och analysera din kod som ren SW-lösning på en multicore-maskin eller på GPU innan du konverterar valda delar till hårdvara.

Det finns en bra preso om OpenCl för FPGA (pdf) av Desh Singh från Altera som visar hur Altera tänker sig att det ska fungera. Från preson är det klart att Altera stödjer både system med FPGA:er på kort i traditionella datorer och system där även processorn implementeras i FPGA:n.

Det finns även en mycket bra artikel från Altera om hur OpenCL är tänkt att fungera (pdf). Artikeln visar hur OpenCL används för att skapa parallella instanser av kernelspecifik logik som processar data. Instanserna styrs sedan av kontrollkod som körs på mjuka processorer i FPGA:n (exempelvis Nios), hårda ARM-kärnor (Altera har FPGA:er med ARM-kärnor) eller x86-processorer.

I artikeln finns även ett prestandatest i form av en Black Scholes. Enligt artikeln är själva OpenCL-koden är på ungefär 300 rader och är porterbar till CPU, GPU och FPGA.

en fyrkärnig Intel Xeon-processor ger 240 miljoner simuleringar/s, en GPU 950 miljoner/s och Alteras Stratix IV-krets 2200 miljoner simuleringar/s.

Slutsatser

För hårdvaruarkitekturer är det en gammal sanning av det är programmeringsverktygen som avgör. Oavsett hur bra, snygg och smart din arkitektur är, kommer ingen att vilja använda den om det inte finns verktyg – program som gör att det effektivt går att programmera applikationer för arkitekturen. Detta gäller microcontrollers, desktopprocessorer, DSP:er, närverksprocessorer. Och FPGA:er.

Jag tror att Altera med satsningen på OpenCL visar att man faktiskt fattar detta och ger sina kunder och användare nya sätt att bygga hårdvara som implementeras i deras FPGAer. Själva poängen är ju för Altera att sälja fler FPGA:er – och gärna genom att hitta nya marknader och kunder än de som traditionellt bygger egna digitala konstruktioner.

Jag ser inte OpenCL som ersättning för C2H. Visst, du kan bygga motsvarande hårdvara med C2H som OpenCL, men egentligen är verktygen för olika typer av problemdomäner.

OpenCL ancvänder du för att bygga parallell hårdvara för att maximera prestanda i problem där du parallellisera upp delberäkningar. C2H använder du för att bygga systemet runt din parallella hårdvara.

När du byggt din AES-kernel till din parallella AES-kryptoknäckare i OpenCL använder du C2H för att bygga paketprocessing och koppla Gbit Ethernet-gränssnitten med AES-motorn. Slutligen lägger du kontrolllkod i Nios II-processorn för att få allt att arbeta ihop.

Heterogent. Inbyggt. I en FPGA-krets. Snyggt.


MQTT – ett nytt protokoll för Internet of Things

Förra veckan meddelade IBM att dom skulle donera ett nytt protokoll till Eclipse Foundation. Protokollet MQTT  (MQ Telemetry Transport) är ett transportprotokoll avsett för meddelanden till och från små Internetkopplade enheter (Internet of Things – IoT).

Vad gäller framtidens Internet tror många – Ericsson, Cisco inte minst att antalet uppkopplade enheter kommer att öka drastiskt, och domineras av saker runt omkring oss. Glödlampor, kylskåp, hissar, dörrar, tvättmaskiner och bilar är bara några exempel på prylar som nämns som tänkbara IoT-saker.

Ericssons vision om Internet of Things-utvecklingen
Ericssons vision om Internet of Things-utvecklingen

Men för att detta ska gå att genomföra måste den intelligens som behöver byggas in i alla dessa prylar vara så kompakt och billig att det inte tillför kostnader. Kostnader såväl vid inköp som användning. Detta ställer stora krav på den tekniska implementationen i alla dess delar för att bli så billig, liten och energisnål som möjligt. Det som krävs är väsentligen:

  • Någon slags strömkälla. I vissa fall kan detta ske genom extern matning. Ett bra exempel är passiva RDID-brickor där avläsaren tillför den ström som krävs. Det pågår även mycket forskning om energy harvesting, vilket innebär olika tekniker att fånga in energi från omgivningen – exempelvis från ljus, rörelser, temperaturskillnader.
  • En kommunikationskanal – oftast en radio, men även enklare trådbunden kommunikation.
  • Eventuella sensorer – om det är så att prylen ska kunna rapportera sitt tillstånd, inte bara en identitet. Tänk en glödlampa där man troligen vill kunna veta inte bara vilken glödlampa det är, utan om den lyser eller inte. Eller om den är trasig.
  • En digital intelligens. Väsentligen en liten processor som implementerar de protokoll, kommandon och funktioner som krävs för att rapportera status, skicka larm ta emot förfrågningar och kommandon som krävs för att göra prylen till en IoT-pryl.
Det MQTT försöker göra är att förenkla kommunikationsprotokollen för att utbyta meddelanden.
MQTT är inte helt nytt. Två tidigare protokoll, SCADA protocol och MQ Integrator SCADA Device Protocol (MQIsdp) är samma sak som MQTT.
Säkerhetsmässigt innehåller MQTT stöd för att skicka lösenord(!). Men för att sökra sessionen föreslår MQTT-teamet att använda SSL.
I samband med donationen bildar Eclipse en arbetsgrupp runt M2M och pressreleasen beskriver syftet med arbetsgruppen närmare.
The Eclipse Machine-to-Machine Industry Working Group and the related open source projects will enable customers to integrate physical world systems into their enterprise solutions,” said Dr. Angel Diaz, vice president, software standards, IBM Software Group. “Data is being captured today as never before, the Eclipse M2M initiative helps expand the spectrum of information and intelligence into the systems and processes that make the world work and become a smarter planet.”
För den som vill veta mer om MQTT finns det massor att läsa, både på MQTT.org. Bland annat finns specifikationen för version 1.3 av MQTT-protokollet (fast specen ligger faktiskt hos IBM). Specifikationen listar några egenskaper med MQTT:
  • The publish/subscribe message pattern to provide one-to-many message distribution and decoupling of applications
  • A messaging transport that is agnostic to the content of the payload
  • The use of TCP/IP to provide basic network connectivity
  • Three qualities of service for message delivery:
    • ”At most once”, where messages are delivered according to the best efforts of the underlying TCP/IP network. Message loss or duplication can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.
    • ”At least once”, where messages are assured to arrive but duplicates may occur.
    • ”Exactly once”, where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.
  • A small transport overhead (the fixed-length header is just 2 bytes), and protocol exchanges minimised to reduce network traffic
  • A mechanism to notify interested parties to an abnormal disconnection of a client using the Last Will and Testament feature
Jag vet inte riktigt hur jag ska ställa mig till MQTT. Att det kommer fram protokoll som gör det enklare (billigare) att implementera maskin-maskin-kommunikation (M2M) och IoT är bra. Det behövs definitvt och protokoll och säkerhetesmekanismer behöver anpassas för att möta de hårda kostnads- och enkelhetskrav dessa prylar ställer.Men jag svårt att se vad som fundamentalt förändras med MQTT. Vad gäller själva säkerheten lämnar protokollet över detta till SSL (och TLS – förhoppningsvis). Men dessa säkerhetsprotokoll är i sig så komplexa och dyra att implementera att kostnaden för transport- och meddelande-protokollet blir marginell.
Vidare blir jag tveksam till varför IBM väljer att donera MQTT till Eclipse Foundation. Eclipse Foundation gör en massa vädligt bra saker och har iaf ett projekt riktat mot M2M (Koneki). Men deras huvudfokus är knappast Internet of Things, och inte heller kommunikationsprotokoll. Varför donerades detta inte till IETF, W3C eller en ren SCADA- eller , M2M-organisation?
Uppdaterad 2011-11-14
Som Jonas påpekar nedan används MQTT av Facebook som del av deras meddelandetjänst. Lucy Zhang, utvecklare på Facebook beskriver deras erfarenhet av MQTT:
One of the problems we experienced was long latency when sending a message. The method we were using to send was reliable but slow, and there were limitations on how much we could improve it. With just a few weeks until launch, we ended up building a new mechanism that maintains a persistent connection to our servers. To do this without killing battery life, we used a protocol called MQTT that we had experimented with in Beluga.
MQTT is specifically designed for applications like sending telemetry data to and from space probes, so it is designed to use bandwidth and batteries sparingly. By maintaining an MQTT connection and routing messages through our chat pipeline, we were able to often achieve phone-to-phone delivery in the hundreds of milliseconds, rather than multiple seconds.

Uppdaterad ECRYPT II-rapport om algoritmer och nyckellängder

ECRYPT II har äntligen publicerat den uppdaterade versionen av sitt dokument ECRYPT II Yearly Report on Algorithms and Keysizes (pdf). (Dokumentet var färdigt i juni, men har publicerats först nu.)

Ecrypt II

Jag anser att detta dokument ger en bra vägledning om var vi står forskningsmässigt vad gäller olika algoritmer, styrkan hos nycklar för olika typer av algoritmer samt ger rekommendationer om minimum nyckellängder att använda. Det jag skulle vilja se är en sammanfattning som listar dom stora skillnaderna gentemot förra årets version. Vad har ändrats och varför. Symmetriska och asymmetriska algoritmer, blockmoder, nycklar, protokoll. Allt finns samlat i ett dokument vilket gör det lätt att få grepp om nuläget.

Om du arbetar med säkerhetsfunktioner på något sätt – kravställning, systemdesign, säkerhetspolicy, design och/eller implementation, tes/verifiering etc är detta ett dokument väl värt att läsa igenom.

Säkerhet och management av miljarder Internetsaker

Ett av det mest intressanta trenderna tycker jag är Internet of Things – tanken att enkla saker ges en enkel, digital intelligens, kopplas upp på Internet och blir en del av informationsflödet. Att koppla upp allt på nätet och därmed göra det möjligt att övervaka och styra ger helt nya möjligheter.

Att exempelvis kunna läsa av och styra enskilda lampor i kontor och fabriker gör det möjligt att optimera ljussättning och därmed energianvädningen mycket mer exakt än idag. Cisco har gjort en mycket snygg illustration som förklarar Internet of Things.

Samtidigt, för att detta ska gå att genomföra behöver vi kunna lita på att de saker vi pratar med verkligen är de saker vi tror att det är. Vi behöver även kunna lita på den information som sakerna skickar. Och dessutom måste det gå att begränsa access till sakerna så att bara den som har rätt att styra sakerna får göra det. Vad det handlar om är klassisk IT-säkerhet och client-server-management – men för miljarder av enheter i komplexitet, noll kronor i kostnad och utan att förbruka energi.

Detta låter inte precis enkelt – och det är kanske till och med omöjligt. Naturligtvis kan inte kostnad och energiförbrukning vara exakt noll. Den forsknings- och ingengörsmässiga utmaningen är att hitta mekanismer (protokoll, system, komponenter) kapabla att skala upp till den komplexitet som det stora antalet enheter ställer, men där den lokala komplexiteten (per enhet) är så låg att den möter kostnads- och energibudget. För inbyggda system, och speciellt där det är systemet som skall läggas till en så enkel sak som en lampa, är kostnaden väsentligen noll. Det enda som räknas är funktionaliteten – och säkerhet är inte en del av funktionaliteten, den är bara ett sätt att säkra funktionaliteten.

Jag tycker dock att det låter utmanande, extremt lockande och jag ser att lösa dessa utmaningar är nyckeln till att visioner som Ericssons 50 Billion Connected Devices 2020 ska kunna lyckas. (Tyvärr ser jag inte att Ericsson pratar om dessa utmaningar i sin presentation, men den handlar i första hand om att sälja in visionen – inte beskriva vad som krävs).

En viktig komponent i säkerhetskedjan är tillgången på bra krypton. Nu vill jag direkt säga en sak: Jag stöter ofta på fall där man av olika skäl kommit fram till att systemet och affären runt systemet (produkten och eller tjänsten) kräver någon form av skydd. Och att man därför landat i att man behöver kryptera. Oftast har man dessutom tagit ett steg till och valt AES-256 som kryptolösning. Inte sällan är detta fel.

Hur kan det vara fel, undrar du säkert? Om vi tar glödlampan som exempel igen. Hur viktigt är det att någon utomstående vet att lampa med ID-nummer 31415926535 är tänd eller släkt – vad skulle kunna hända om den informationen kom i orätta händer? Det kan säkert finnas scenarion där det kan vara viktigt.

Det som är antagligen är mycket viktigare är att veta att statusinformationen verkligen kommer från 31415926535 och att du kan lita på att informationen är korrekt. Det som annars skulle kunna hända är att lampa 31415926535 och dess 10000 kompisar som används för att belysa Volvos nybilsparkering är släkta/trasiga och att tjyven kan härja fritt, men att du tror att dom är tända.

Det som oftast krävs är därför pålitliga identiteter och skydd av ett meddelandes integritet (så att ingen kan pilla på meddelandet utan att det upptäcks av mottagaren). Och ibland även att meddelanden inte går att läsa för den som inte är behörig – att meddelandet är konfidentiellt för andra än sändaren och mottagaren.

Ett symmetriskt krypto som AES ger i första hand konfidentialitetsskydd. Det kan även används för att ge integritetsskydd och identitetskontroll och förutsätter att sändare och mottagare på något sätt redan kommit överens om nycklar. Vanligare är att asymmetriska krypton (kallas även krypto med publika nycklar) och hashfunktioner används att etablera identitet och integritet.

Tyvärr är det svårt att hitta bra algoritmer som inte kostar för mycket. Speciellt asymmetriska algoritmer finns det för närvarande inga som egentligen fungerar för Internet of Things. Det som är positivt är att problemet har börjat uppmärksammas. EU-sponsrade ECRYPT II anordnar i november en konferens i ämnet. På konferensen CRYPTO 2011 hölls en rump session där Danilo Gligoroski presenterade del resultat som visar på mycket snabbare/effektivare asymmetriska krypton.

Även protokoll som inte är för komplexa, men samtidigt säkra behöver utvecklas. IETF anordnade i mars en workshop om problemställningarna runt Internet of Things, men än är det långt tills vi har standarder att bygga på.

Secworks gör uppdrag riktat mot utvecklingen av Internet of Things, och kommer att bevaka och försöka bidra till att få fram de teknologier som krävs. Jag kommer därför att posta mer om utvecklingen av säkerhet och management för Internet of Things här. Bland annat om de riktigt kompakta algoritmer och implementationer som faktiskt finns redan i dag. Häng med!

Extrahera kod från låst minne i processorer

Andrew Shane Bunnie Huang, troligen mest känd för att han en gång i tiden var den som knäckte skyddet i Xbox har en klart läsvärd blogEn i mitt tycke ytterst intressant postning på bloggen handlar om hur Bunnie undersöker säkerheten hos Microchips PIC-processorer. Mer exakt processorer från PIC18-serien.

Microchip PIC18F
Microchip PIC18F

Precis som i många andra typer av microcontrollers har PIC mekanismer för att skydda det program som skrivs ner till det inbyggda programminnet från att kunna läsas ut igen. Detta sker oftast genom skrivbara låsbitar eller programmerbara säkringar. Det Bunnie ville ta reda på var hur svårt det är att återställa låsbitarna till det läge som tillåter utläsning av innehållet i det interna programminnet. Genom att skrapa bort toppen av kapseln går det att komma åt själva kiselbrickan, vilket är vad Bunnie gjort:

Kapseln bortplockad.

Det Bunnie vet är att PIC använder FLASH-minne för lagring av program och konfiguration. Bunnie ger en bra förklaring till släktskapet mellan minnesteknologierna EPROM och FLASH. Det han förklarar är att, precis som för EPROM, kan FLASH-cellers tillstånd påverkas av att belysas energirikt ljus (ex UV-ljus).

Gammalt fint EPROM-chip
Gammalt fint EPROM-chip

 

 

 

 

 

 

(Hittade bilden ovan på Wikipedia och kunde inte motstå att ta med det av ren skönhet.)

Att tillståndet i minnescellerna för EPROM påverkas av att belysas med ex UV-ljus utnyttjas genom att sätta in ett fönster i kapseln vilket gör det möjligt att radera kretsen bara genom att lysa på den. För att skydda mot motsvarande manipulation har Microchip lagt på ett extra metall-lager för att förhindra att någon genom att lysa på kretsen skall återställa låsbitarna. Så synd att metallen fungerar utmärkt som spegel.

Studsa ljus in under metalllagret.
Genom att lysa snett ovanifrån kan Bunnie få UV-ljuset att studsa på undersidan av metall-lagret och den vägen belysa låsbitarnas minnesceller även om dom är täckta av metall-lagret. Att belysa med UV-ljus raderar tyvärr även innehållet i det minne Bunnie vill extrahera. Som tur är finns tejp. Ett lager tejp över minnet går det utmärkt att resetta bitarna och få ut innehållet i minnet.

Bunnies chip med tejp över FLASH-minnet.
Bunnies chip med tejp över FLASH-minnet.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Genom att testa att skriva ner till minnet, sätta låsbitarna och sedan lysa lyckas Bunnie hitta rätt belysningsvinkel och vilka delar av kretsytan som behöver maskas för att framgångsrikt återställa låsbitarna utan att förstöra innehållet i minnet.

Så hur ska man tolka Bunnies hack? Jag tycker att det finns ett par saker man kan notera. En första sak man kan se är att det inte är speciellt svårt att komma åt och identifiera funktioner på ett chip – samt att ett chip är mer tåliga än man kan tro. Att skrapa bort kapseln och köra nedcabbat funkar fint, i alla fall på kort sikt.

Vad gäller själva låsfunktionen känns det som PIC har gjort det enkelt för sig. Hade låsbitarna varit utformade som komplementära par av celler, dvs där ena cellen måste vara satt och den andra nollställd för att läsning hade varit tillåten hade Bunnies attack behövt bli mycket mer exakt då han behövt belysa enskilda celler. Andra tillverkare har mer komplicerade lösningar, även inklusive riktiga säkringar som bränns av. Dessa går dock också att reparera.

Så hur ensam är Bunnie i att kunna göra det här? Antagligen inte speciellt ensam. Det han gör är i grunden inte speciellt svårt. Har man bara ett försök på sig och aldrig gjort det förut är det stor risk att man misslyckas. Men får man öva borde det gå att metodiskt få till en process som fungerar med låg felprocent. De chip vi pratar om här är billiga så att köpa en hög kretsar att öva på är ingen stor kostnad.

Det finns ett antal företag som erbjuder sig att extrahera kod från microcontrollers – alltid i utbildningssyfte eller som tjänst till företag som tappat bort sin källkod. Googlar man på MCU code recovery (MCU – Microcontroller Unit, dvs en liten kontrollprocessor för inbyggnad) hittar man bla Mika Technology, Gexin, Starlight samt företaget med det något avslöjande namnet MCU Crack.

Uppsprättat chip från MikaTech

MikaTech (som även finns på break-ic.com) , vars företagsslogan är Everything they make, we can break!, förklarar syftet med sina tjänster så här:

Our service is only to help engineers to study the up-to-date technologies on educational purposes and help you develope better security solutions

I samtliga fall erbjuder företagen ungefär samma upplägg. Oftast är det betalning vid start som gäller och du får lita på att dom levererar. En annan sak företagen har gemensamt är de långa listor med olika typer av MCUer, CPLDer, DSPer och FPGAer de säger sig kunna extrahera innehållet ifrån. Dom anger sällan priser direkt, men Googling ger att ca 1000 USD är kostnaden för att extrahera koden från en PIC-processor. Jag är osäker på hur trovärdiga dessa företag är, en antalet företag och det likartade upplägget pekar på att det antingen är ett utbrett bedrägeri, eller att det tyvärr är en fungerande, mogen marknad.

Så vad är då slutsatsen? Att enbart lita på att om du sätter låsbitarna i din MCU så är ditt program och hemligheter lagrade i processorns minne skyddade för alla former av attacker är anser uppenbarligen inte ett korrekt antagande. Jag har träffat representanter från leverantörer av MCU:er som hävdar att det är omöjligt att klona innehållet i deras processorers minnen. Förhoppningsvis visar detta att det inte är helt sant.

Det känns besvärligt att inte kunna komma med någon bra rekommendation på mekanism som skyddar mot den här typen av fysiska attacker. Tyvärr känner jag inte till något bra sätt att skydda sig. Det går att tänka sig aktiva skalskydd, men någon generell metod som ger bra skydd till ett pris som fungerar för att skydda microcontrollers mot fysisk kloning vet jag inte om det finns. Det pågår forskning om att ta fram icke kloningsbara funktioner (physically unclonable functions – PUF). Därmed riskerar detta att bli en skrämselartikel, vilket jag inte gillar.

Jag hoppas få anledning att skriva mer om detta och kunna presentera bra sätt att skapa bra skydd mot denna typ av fysiska attacker.