Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1222
Hårdvara » Kryptoblog

Archive for the ‘Hårdvara’ category

Bra bok om multicore för inbyggda system

September 7th, 2009

Processorföretaget Freescale har släppt en bra bok om multicore för inbyggda system. Boken är skriven av Jakob EngblomVirtutech, Patrik Strömblad på Enea samt Jonas Svennebring och John Logan på Freescale. Boken använder Freescales processorer för att exemplifiera, men är väl värd att läsa för att få en generell inblick om problem och möjligheter samt vad man bör tänka på när man designar för multicore-processorer.

Cellautomatbaserad slumptalsgenerator på OpenCores

September 1st, 2009

I början av 2009 släppte vi på InformAsic ett hårdvarublock (en IP-core) för en specifik typ av slumptalsgenerator (PRNG) byggd på en cellautomat (CA) med uppdateringsregeln rule30. Vi har nu uppdaterat den konstruktionen och ca_prng är nu en generell CA-baserad PRNG där uppdateringsregeln går att byta ut. Detta gör det möjligt att generera ett stort antal mönster, från vitt brus till vandrande ettor, Pascals triangel m.m.

Samtidigt har vi flyttat konstruktionen och ca_prng finns nu på OpenCores. OpenCores är en webbplats för hårdvarukonstruktionsprojekt tillhandahållna som öppen kod. Licensen vi använder är dock fortsatt BSD och konstruktionen är skriven i Verilog (2001). Vi är glada att bidra till OpenCores och hoppas att ca_prng skall komma till nytta, exempelvis som stimuligenerator vid FPGA-accelererad verifiering av konstruktioner.

Uppföljning om USB-modemet

March 31st, 2009

Först ett tack till de som hört av sig med tips på hur man löser problemet med att få Huawei E220 att fungera på en ny maskin. Love Hörnquist Åstrand tipsade om Hua, ett verktyg han utvecklat som gör att man kan kontrollera vilket nätverk som väljs som standard.

Jag löste problemet genom att koppla in USB-modemet i datorn och sedan installera uppdateringar för firmware och programvara från den virtuella Windows XP-maskin jag har i Suns ypperliga virtualiserare Virtualbox. Efter att ha gjort dessa uppdateringar gick det utmärkt att få koppling i Mac OS X.

För att återigen hitta en koppling till säkerhet är det inte så lätt att försöka rita upp kommunikationsvägarna jag (temorärt) hade i mitt system. Jag hade alltså en USB-modem fysiskt inkopplat i min laptop. USB-modemet kopplades via Mac OS X till en applikation (Virtualbox) och in i det virtuella OS:et Windows XP. I Windows gjorde en applikation uppdateringar på firmware-nivå hela vägen tillbaka. Samtidigt finns det en koppling mellan Windows XP och Mac OS X via foldrar (av Vbox hanterade delade resurser) och virtualiserat nätverksinterface. Sätten som data kan flöda mellan olika producenter och konsumenter och konsumenter inom och utanför mitt lokala system blev för en stund j-kligt många.

Inte konstigt att virtualisering enl den undersökning som Clavister gjort ser ut att leda till att system plötsligt blir öppna för attacker. När man virtualiserar förändras säkerhetsmodellen för sitt system.

BTW: Tror du att molnet kommer att göra det lättare eller svårare att hålla koll på säkerheten?

Dagens datorstrul

March 22nd, 2009

Det här har inte så jättemycket med IT-säkerherhet och krypto att göra. Men när jag fick min nya MacBook-laptop och skulle försöka använda mitt USB-modem fungerade det inte alls. Jag har på olika sätt försökt replikera inställningarna på min gamla maskin (där det fungerar), men än så länge utan framgång.

Ett tips jag fått är att uppgradera programvaran för USB-modemet, en E220-dongle från Huawei. Tydligen finns det en ny programvara med Plug & Play-stöd för Mac OS X för de som är Macanvändare. Tyvärr är det inte så lätt installera uppgraderingen om man är Macanvändare:


Uppgraderingen gäller bara USB-modemet Huawei E220 och kan endast göras ifrån Windows. Den här uppgraderingen innehåller stöd för Windows Vista, plug n play för Mac OS X, stöd för Mac OS X Leopard samt stöd för 7.2 Mbps.

Hur tänkte dom nu? 😉

Skall vi hitta på en säkerhetskoppling kan det väl vara att installation av säkerhetsuppgraderingar (vilket detta iofs inte är) skall vara enkla att utföra.

CUDA på Mac

March 16th, 2009

Jag har nyligen blivit med en ny laptop, en Apple MacBook Unibody:

MacBook

Förutom mer minne och större hårddisk, vilket gör det lättare att köra de virtuella system jag använder vid hårdvaruutveckling kommer maskinen med praktiska funktioner som bakgrundsbelyst tangentbord (iaf praktiskt om man sitter uppe på nätterna.)

En annan bra sak med den nya laptopen är att den kommer med en grafikprocessor (GPU) från Nvidia kapabel att stödja Nvidias programmeringsmiljö CUDA. Compute Unified Device Architecture (CUDA) gör det möligt att relativt enkelt accelerera applikationer med dataparallellism genom att exekvera beräkningar parallellt på grafikprocessorn.

Jag testade att installera CUDA 2.0 på laptopen förra veckan. Installationen gick i stort sett utan några problem alls, speciellt efter att ha hittat den här utmärkta bloggpostningen om att installera CUDA 2.0 på Mac. Följer man instruktionerna kan man snart testa CUDA på sin maskin:


js@stajlis.springfield.se:/Developer/CUDA/bin/darwin/release>./deviceQuery
There is 1 device supporting CUDA

Device 0: “GeForce 9400M”

Major revision number: 1 Minor revision number: 1 Total amount of global memory: 266010624 bytes Number of multiprocessors: 2 Number of cores: 16 Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 16384 bytes Total number of registers available per block: 8192 Warp size: 32 Maximum number of threads per block: 512 Maximum sizes of each dimension of a block: 512×512 x 64 Maximum sizes of each dimension of a grid: 65535×65535 x 1 Maximum memory pitch: 262144 bytes Texture alignment: 256 bytes Clock rate: 0.80 GHz Concurrent copy and execution: No

16 beräkningsenheter är inte precis enormt många, iaf inte i jämförelse med Nvidias Tesla. Nåja, det går dock att köra CUDA utan problem och Nvidias exempelapplikationer uppvisar en tydlig acceleration jämfört med en entrådars CPU-implementation. Jag upptäckte även att en totalt överspecad CUDA-applikation (ex nbody-applikationrn med 65535 kroppar att beräkna) totalt sänker Mac:en.

Slumptalsgeneratorn Mersenne Twister i CUDA-variant ger på min maskin följande prestanda:


js@stajlis.springfield.se:/Developer/CUDA/bin/darwin/release>./MersenneTwister
Using device 0: GeForce 9400M
Initializing data for 24000000 samples…
Loading CPU and GPU twisters configurations…
Generating random numbers on GPU
Generated samples : 24002560
RandomGPU() time : 77.352997
Samples per second: 3.102990E+08
Applying Box-Muller transformation on GPU
Transformed samples : 24002560
BoxMullerGPU() time : 35.231998
Samples per second : 6.812716E+08
Reading back the results…
Checking GPU results…
...generating random numbers on CPU using reference generator
...applying Box-Muller transformation on CPU
...comparing the results
Max absolute error: 2.264977E-06
L1 norm: 1.783765E-07

Jag har inte hunnit att hacka några egna CUDA-program. Förra året testade jag (min vana trogen) att koda strömkryptot RC4 i CUDA. Inte speciellt förvånande nog gav det dock ingen prestandaökning. Det var dock mer ett test av att jag fattat hur man kodar för CUDA. Skall försöka hinna koda lite CUDA under våren och då pröva med mer parallella algoritmer och applikationer.

Senare i år kommer (om tidplanen stämmer) Mac OS X 10.6 – Snow Leopard. I och med det borde det även finnas SDK på Mac för att koda för OpenCL, vilket verkar vara mindre yxigt och primitivt än CUDA. Återstår dock att se om det är så, när 10.6 väl dyker upp.

För den som vill testa CUDA har Raymond Tay som postade beskrivningen av installationen även postat en bra lista med CUDA-resurser. Om du testar CUDA och hackar några spännande algoritmer får du väldigt gärna posta kommentarer.

PS: En sak jag inte gillar med min nya Mac är att tangenterna skramlar. Speciellt mellanslagstangenten låter klonk modell en gammal Apple II. Men annars är den riktigt stajlish.

Kör beräkningar på din PS3:a

March 1st, 2009

(Har haft dom här länkarna liggande på tok för länge i min lista med intressanta saker…)

Enligt en artikel på Physorg har några forskare på Dartmouth-universitetet släppt ett system + instruktioner för att köra parallella beräkningar på en Sony PlayStation 3 (PS3).

Jag har inte testat på min egen maskin (än), men att döma av webbsidan för systemet är det ganska rätt fram att installera och köra. Är det någon som testat och har några åsikter skulle jag uppskatta en kommentar.

rule30 IP-core släppt

January 12th, 2009

I dag släppte vi på InformAsic den cellautomatbaserade slumptalsgenerator byggd på rule30 jag byggt som öppen IP-core. Det tog lite längre tid att få ut den än jag hade hoppats, men nu blev det en bra start på nya arbetsåret.

För den som vill titta på och använda vår IP-core finns den här. Koden är BSD licensierad. Skriven i Verilog (naturligtvis). Förhoppningsvis kommer den till nytta för att exempelvis driva FPGA-baserad test med kontrollerad, slumpmässiga indata. Det är så jag ex använder den för att testa kryptoimplementationer.

Glädjande nog fick vi en del uppmärksamhet för släppet, bland annat i Elektroniktidningen och Elektronik i Norden. Ett litet förtydligande angående Opencores och Sourceforge är att vi på InformAsic tycker att dessa är mycket bra initiativ.

Dock är Opencores en aning (lite väl) knölig att använda, både för utvecklare och användare av cores. Tittar man på många av de (ex Rudolf Usselman) som var med att starta Opencores bor deras cores i dag på andra platser även om det finns information om deras core på Opencores. En sådan lösning skulle säkert kunna fungera för oss också. Vi får se hur vi gör nästa gång, speciellt när vi snart släpper nästa öppna IP-core.

Faran med minnesbaserade hårddiskar

December 15th, 2008

För ett tag sedan bloggade jag om en IDG-artikel som tog upp säkehetsproblemet med minnesbaserade hårddiskar. Då handlade det om huruvida det är svårare eller enklare att komma åt information som är lagrad på hårddisken.

I går kom det ett par inlägg på Cryptography-listan som satte fingret på ett helt annat, och mycket intressant problem: Att hårddiskar används som entropikälla för att driva slumptalsgeneratorer (PRNG) i operativsystem.

James A Donald skrev i ett inlägg om entropikällor för slumptalsgeneratorer:


If one uses a higher resolution counter – sub microsecond – and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true
random.

Ett inlägg Damien Miller svarade på med:


Until someone runs your software on a SSD instead of a HDD. Oops.

Japp, Oops är helt rätt. Hur många OS använder hårddiskens accesstider som entropikälla, och hur många tänker på att entropikällornas beteende ändras när man byter teknik som det här? Jag har iaf inte tänkt på det innan.

En annan sådan källa som förekommer är tid mellan inkommande frames på Ethernetportar. Min magkänsla säger att trenden mot att skapa virtuella nätverk mellan virtualiserade servrar borde göra att den källan till entropi blir mindre värd att lita på. Över huvud taget borde virtualisering innebära problem för entropikällor då poängen med virtualisering är att ersätta fysisk hårdvara med programimplementationer.

Vad tror du?

VISA-kort med inbyggd kodgenerator

December 7th, 2008

New York Times skriver om en ny typ av VISA-kort som innehåller en generator för engångskoder. Kortet är utrustat med ett numeriskt tangentbord samt en display.

VISAs kort.

När en kod skall genereras används tangentbordet för att mata in den PIN-kod som autenticierar dig mot kortet. Kortet genererar en engångskod, vilken visas på displayen. Den genererade koden används för att elektroniskt autenticiera kortet.

Konstruktionen motsvarar alltså det ex SEB och Swedbank åstadkommer med sina dosor från Vasco, men nu behöver man inte släpa runt på dosan (jag har aldrig upplevt att det är speciellt betungande) då den finns i kortet.

Jag tycker att detta är en mycket smutt lösning. Dock tycker jag att jag sett liknande teknik förut, bland annat från svenska Cypak.

Låsa upp en iPhone – Vietnam Stylee

December 2nd, 2008

Cnet har en artikel om hur man låser upp en iPhone i Vietnam. Metoden man använder är fysisk och inte alls speciellt sofistikerad.

Telefonen sprättas upp och en tekniker plockar loss moderkortet i telefonen:

En iPhone som sprättas upp.
Teknikern sprättar upp telefonen. (Notera kylningen på arbetsbordet.)

Moderkortet i en iPhone
Det utplockade moderkortet.

Kretsen med kryss monteras loss och placeras i en kretsprogrammerare.

Kretsen bortplockad.
Kretsen bortplockad.

Med hjälp av en hexeditor ändras sedan innehållet i kretsen så att spärren för att prata med olika operatörer stängs av (elimineras/slås ut). Sedan monteras kretsen tillbaka.

Kretsen monteras.
Kretsen monteras på kortet. Tydligen med en varmluftspistol!

Inget avancerat script som ändrar i OS:et eller andra SW-hack, utan rätt in på kortet och modda. Kretsen som lossas sitter i en BGA-kapsel, dvs kontakteringen består av lödbollar på kapselns undersida, vilket normalt sett gör det väldigt svårt att komma åt kontakteringen för hand. (I artikeln hävdar man att man lossa på limmet samt limmar tillbaka kretsen, men det är imho fel.)

Detta förklarar varmluftspistolen, men att de lyckas lossa och dessutom montera tillbaka kretsen utan att skada den är imponerande. Och dessutom i en arbetsmiljö om med en utrustning som skrotbordet i min källare.

I artikeln hävdar man att det är basbandskretsen i telefonen som lossas och programmeras om. Det låter otroligt, och tittar man på den här bilden från en teardown av iPhone ser man att det inte är basbandskretsen:

Moderkortet i iPhone - nu med kretsbeskrivning.

Som synes är det kretsen bredvid basbandskretsen från Infineon som lossas. Den kretsen är ett Pseudo-SRAM från NUMONYX. Egentligen är det ett NOR-FLASH-minne som lagrar firmware för basbandskretsen.