31c3

Käisin läinud aasta lõpus 31C3’l, millest allpool toodud mõned mälestused ja mõtted.

Chaos Communication Congress (CCC) on igaastane, 4 (öö)päevane Saksamaal toimuv rahvusvaheline häkkerite kokkusaamine. Seekord toimus konverents 31 aastat ja on kasvanud väga suureks (~13k osalejat). Toimumiskohaks on Hamburgi konverentsikeskus, mis on oma olemuselt selline hiiglaslik labürint hoone. Ka kolmandal päeval avastasime veel mingi korruse, kus polnud varem käinud.
hamburg conference center 31c3

Üldiselt on konverents jagatud loogiliselt erinevateks teemadeks (Isetegemine, Tehnoloogia, Häkkimine, Teadus, Kunst, Poliitika ja ühiskond jne.)
Põhikava toimus paralleelselt neljas suuremas saalis, lisaks oli ka mitusada väiksema töötuba jms. üritust.

tetris_door_1024

Kogu ürtuse aja kestsid ka mitusada rahvakogu, mis on põhimõtteliselt sellised projekti/organisatsiooni spetsiifilised lauad, kus saab vastava teemaga tegeleda.
Näiteks sai seal tutvuda 3d printimisega, sõrmuste valmistamise, droonida, robootika, kudumismasinate, lukkude muukimise ja kõikvõimalike muude asjadega. Muuhulgas oli võimalik ka näiteks ööpäevaringselt jootmist õppida 😛

Lisaks tegutses veel ka ööpäevaringne peoala DJdega (kuhu me küll väga ei läinud sest suitsuhais mattis hinge).

31c3 sitting shadow

Konverentsi korraldavad vabatahtlikud ja kuskil 10% külastajatest aitavad ühel või teisel viisil kaasa. Ilmselt on aastatega korraldust viimse detailini lihvitud ja üldjoontes oli kõik perfektne ja saksa täpsusega tehtud. Näiteks kuni viimase hetkeni püsis kõik graafikus, wifi toimis laitmatult (tipus korraga 7800 kasutajat), kõik ettekanded olid üle maailma live streamidena kättesaadavad jne. Paar väiksemat probleemi oli — näiteks suudeti ürituse wiki teise päeva õhtuks maha tõmmata (nagu kuuldavasti ka eelnevatel aastatel) ja lõppsõna oli vastupidiselt päevakavas lubatule inglise asemel saksa keeles.

Puht tehniliselt on ka tegu üsna mastaapse ettevõtmisega, näiteks on ürituse välislink suurem kui mõnel riigil, toimisid lokaalsed DECT ja GSM võrgud, videot kanti lokaalselt üle ka DVB-Tga, oli oma kiirabi laadne värk koos laatsaretiga, mingi lastehoiu laadne värk jne. Üles oli muuhulgas pandud ka pneumaatiliste torude süsteem asjade saatmiseks mööda maja (rohkem ilmselt küll huumori huvides) ja IRC kaudu sai tellida pizzat (ilmselt seda võimalust elus rohkem ei avane ;-)).

pneumatic intercept

Konverentsil on keelatud teha pilte ilma kõigilt pildil olevatelt inimestelt nõusolekut küsimata. Kuna see on 13k inimese seas pehmeltöeldes raske siis konverentsist väga palju pildimatejali pole. Kuid midagi leiab näiteks Flickr’ist.

Kuna tegu on eeskätt häkkeritele suunatud konverentsiga, siis algasid loengud iga päev mitte varem kui 11:30 kuid
kestsid vähemalt südaööni välja. Kella 1 ajal öösel oli üldiselt maja peal palju rohkem elu ja liikumist kui 11 ajal hommikul 🙂

31c3 star trek corridor

Ürituse spetsiifikat arvestades algas õpetlik moment tegelikult juba enne konverentsile jõudmist.
Kodus sai üle pika aja tehtud korralikud varukoopiad läpparist ja telefonist.
Enne esimesel päeval hotellist lahkumist veetsin tunnikese läpparis ebaolulisi teenuseid sulgedes ja tulemüüri confides.
Telefoni hoidsin enamiku ajast lennureshiimis jne.
Üritusel läpakalt või telefonilt ekraanilukku maha võttes oli üsna kõhe tunne, kuna pidevalt oli kahtlus, et keegi raudselt seljatagant jälgib või filmib.
Tundub, et läks üldiselt õnneks ja seekord keegi minu seadmetesse sisse ei häkkinud aga oli kuulda, et kõigil nii hästi ei läinud.
Lisaks oli kuskil wikis näha ka tabelit väliste saitidega, mis on konverentsil osalejate poolt maha häkitud.

Sisust

Alljärgnev on kokkuvõte minu jaoks huvitavamatest teemadest. Nagu mainitud toimus pidevalt paralleelselt 4 ettekannet, seega ma viibisin neist maksimaalselt veerandil. Neist omakorda on allpool kirjeldatud mingi mulle olulisemana tundunud alamhulk.

Mobiilindus

Selle aasta fookuseks oli SS7 võrk, mida kasutavad mobiiloperaatorid omavaheliseks suhtluseks (roamingu teemad, SMS jms.). Antud võrgu ligipääsu omades on teades ainult telefoni numbrit võimalik muuhulgas jälitadata suvaliste telefonide asukohta üle maailma, võtta vahelt nende kõnesid jms.

Selgub, et sellist ülemaailmset jälitusteenust müüakse suisa kommerts tootena. Omal ajal (80ndad) kui see protokoll disainiti oli vähe osapooli ja suhtlus käis üle spetsiaalsete füüsiliste kanalite, seega mingit autentimist sisse ehitatud pole ja osapooled usaldavad teisi pimesi. Tänapäeval on SS7 võrgule ligipääsu saamine aina lihtsam. Esinejatel oli see igatahes kuskiltkaudu olemas ja liveis demonstreeriti näiteks kõne vaheltvõtmist.

  • SS7: Locate. Track. Manipulate See ettekanne keskendus SS7 rünnakutele
  • Mobile self-defense Siin räägiti alustuseks osaliselt sarnast SS7 teemat, mida eelmiseski ettekandes. Lõpupoole avalalikustati nende ja ka muude rünnakute (võlts tugijaam, nõrk võrgu krüpto) avastamiseks loodud Androidi rakendus SnoopSnitch. Soovitan kõigil kellel sobiva kiibistikuga root‘itud Androidi telefon seda proovida. Selle rakenduse põhjal saab paremat infot ka GSMMap, mis on selline crowd-sourced ülevaade selle kohta, kui turvalised on eri riikides mobiilvõrgud. Selle ettekande põhisõnum oligi, et operaatorid üldiselt pigem ei tee turvalisust omal algatusel paremaks ja neid peab selleks avaliku häbistamise hirmuga sundima. Et seda oleks võimalik teha ongi vaja andmeid koguda.

TR-069

Too Many Cooks – Exploiting the Internet-of-TR-069-Things TR-069 on kliendiseadmete (CPE) haldamise protokoll, läbi mille näiteks ISPid oma klientide ruutereid haldavad. Protokoll nõuab, et seade kuulaks HTTPd TCP pordil 7547 ja seal vastab sellistel väheste resurssidega seadmetel tihtipeale RomPager nimeline veebiserver. Üldjuhul on ka uusimatel hetkel müüdavatel seadmetel sellest ürgne versioon (versioon aastast 2002). Käidi välja mitmesugust päris huvitavat statistikat:

  • ~45m avalikust võrgust ligipääsetavat TR-069 klientseadet üle maailma
  • avatud portide arvult on TR-069 HTTP järel internetis teisel kohal
  • ka HTTP serveritest on kuskil 50% igasugu sardsüsteemid/IoT asjad (~35m seadet)
  • TR-069 avalikest klientidest on kuskil 50% RomPager veebisereveriga ja neist omakorda 98.04% kasutab versiooni 4.07 aastast 2002
  • osades riikides ~50% IPdest haavatavad

Demoti mitmeid lihtsaid rünnakuid selle softi versiooni vastu ja näitavad, kuidas nende Chrome pluginiga saab admin õigustes vabalt CPEsse sisse. Õpetlik on selle loo juures mitte niiväga konkreetne exploit vaid see, et sellistel embedded seadmetel üldiselt puudub igasugune variant nii firmwarei up-to-date hoidmiseks, kui tegelikult isegi HTTP serveri tarkvara tootjalt paranduste jõudmiseks kasvõi seadme tootjani (kes ei ole ahelas veel viimane lüli). Ühesõnaga on nii CPEde puhul konkreetselt, kui ka embedded/IoT teema puhul laiemalt tegu väga viljaka pinnasega ründamiseks, millest hakkame ilmselt aina enam kuulma seoses sedasorti seadmete massilise lisandumisega.

SCADA

SCADA on protsessijuhtimise süsteem, mis praktikas tähendab igasuguste tehaste ja suuremate seadmete (majade ventilatsioon, tammid jms.) juhtimist. Viimastel aastatel on toimunud mitmeid tõsiste füüsiliste ja rahaliste järelmitega küberrünnakuid selliste süsteemide vastu, näiteks Iraani uraani rikastamise tehases seadmeid rikkunud Stuxnet või Türgis gaasitoru õhkimine. Turva uurijad on hakanud antud valdkonda aina enam uurima ja kajastama ja tulemused on üsna masendavad, kuna tundub et SCADA maailmas pole küberrünnakuid kuigi tõsiselt võetud ja usutakse security by obscurity printsiipi.

  • SCADA StrangeLove: Too Smart Grid in da Cloud Ülevaatlik ettekanne erinevatest viimase aasta uutest rünnakutest uurijate grupilt, kes on SCADA ründamisele keskendunud. Näitasid muuhulgas rünnakuid erinevate päikese-, hydro-, tuuleelektrijaamade vastu, ühel või teisel viisil avaliku interneti kaudu rünnatav vähemalt 8GW võimsust. Muuhulgas näidati rünnakut ka kontrolleri softi vastu, mida kasutatakse LHCs ja gaasitorude juhtimises. Üldisest turvatasemest antud valdkonnas annab aimu, et kui nad kuulutasid välja avaliku 2 päevase ligipääsu oma laboris olevatele seadmete ründamiseks siis leiti üle 10 uue turvaaugu. Lisaks on tarkvara uuendamisega lugu sarnane nagu eelpool TR-069 puhul – jooksutatakse 10+ aastat vana teada aukudega tarkvara ja mingit selget uuendamise kanalit tegelikult polegi. Tegeletakse siis kui põleb, ilmselt sõna otseses mõttes 😛
  • Damn Vulnerable Chemical Process Rääkis virtuaalse õppekeskkonna loomisest protsesside/tehaste ründamise harjutamiseks (analoogne siis veebirakenduste maailmast Damn Vulnerable Web App‘ile). Päris huvitav tähelepanek oli, et süsteemi sisse saamise järel tegelik töö alles algab ja tuleb aru saada kuidas konkreetses tehases protsess töötab (igaüks unikaalne) ja kuidas seda kõige mõistlikum enda kontrolli all olevate kraanide ja sensoritega teha annaks. Eeldab põhjalikke valdkonna teadmisi (vähemalt kui eesmärk on mingi peenem rünnak, kui lihtsalt kõige vastu taevast laskmine).
  • Switches Get Stiches Seda ma ise vaatama ei jõudnud aga kuna kirjeldab tööstuslikke etherneti switchide vastaseid rünnakuid, mida Damn Vulnerable.. jutust viidati siis täielikuse huvides mainin ära.

Tor

  • State of the Onion Igaastane ülevaade Tor võrgu arengust. Kirjeldati viimase aasta jooksul toimunud Tori vastaste rünnakute olemust. Tundus, et parim hetkel teadaolev rünnak on liikluse korreleerimise rünnak, mis on üsna efektiivne, kuid eeldab NSA sugust ründajat kes suudab üle maailma liiklust paljudest punktidest salvestada ja suhteliselt pikaajaliselt talletada. Nenditi, et hetkel head rohtu sellise ründaja vastu pole. Paraku ei paista olevat hetkel ka paremat alternatiivi seega, kui tahad privaatsust siis palju variante rohkem polegi. Meeldejäävaim mõte oli, et kõik peaksime kõigile oma lähedastele rääkima, mis on Tor ja miks me seda kasutame ja vajame. Seda selleks, et ei saaks tekitada ülduses muljet, et see Tor on ilmselt mingite abstraktsete kurjamite tööriist vaid, et see ongi asi mida kasutab su enda poeg, vend, sõber, kolleeg jne. oma igapäevaelus.
    Lisaks räägiti Open Observatory on Network Interference projektist, mis pakub avatud lähtekoodiga tarkvara, mille abil analüüsitakse kas ja kuipalju eri riikides internetti tsenseeritakse.
  • Tor: Hidden Services and Deanonymisation Esitleti uuringut, mis üritas leida vastust küsimusele, mida sisaldavad Tori peidetud teenused. Paistis, et peamiselt lastepornot. Tekkis arutelu ühest küljest mõõtmis metoodika üle. Väidetavalt on tor võrgus tavaline et paljud lastekaitseorganisatsioonide spiderid tsüklis kammivad selliseid lehti, mis annab kallutatud pildi. Teisest küljest arutleti küsimuse üle kas annaks midagi selle vastu ette võtta või mitte (suvalise asja blokeerimise võimekuse olemasolu süsteemis võimaldab blokeerida ka misiganes muu asja mis poliitiliselt vms. põhjusel kellegile ei meeldi). Siin ka Tori poolne kommentaar sellele ettekandele.

Turvaline progemine

  • Why are computers so @#!*, and what can we do about it? Üks humoorikaimaid ja nauditaivamaid ettekandeid üritusel. Rääkis, nagu pealkirigi ütleb sellest, miks meil tarkvaraga pidevalt igasugu jamad on ja kuidas saaks teha töökindlamat tarkvara. Esineja uurimisala oli tegelikult formaalse ja testitava prose spetsifikatsiooni loomine. Väitis, et tegelikult tänaste protsessori dokude pealt polegi võimalik üheselt öelda kuidas mingi asi käituma peaks (sest kirjutatud inimkeeles, mis lihtsalt ei ole piisavalt ühetähenduslik).
  • Trustworthy secure modular operating system engineering Räägiti Mirage OSist, mis on teadusprojekt kirjutada nullist turvalisem “OS” täielikult OCamlis. OS sellepärast jutumärkides, et pigem on see teekide hulk, mida iga rakendus vastavalt vajadusele endasse impordib. Jutu üldmõte oli, et viskame kõik aastakümnetega kogunenud abstraktsioonikihid (nagu näiteks failisüsteem) minema ja alustame nullist. See jutt kõlab üldiselt sellise klassikalise uue õhukese frameworki alustamise jutuna, mis lõpetab peale kogu vajaliku funktsionaalsuse lisamist samasugusena nagu ta eelkäia. Ühtlasi peaksid kõik selle fantaasia teostumise puhul kõike OCamlis kirjutama. Mitte, et mul otseselt midagi OCamli vastu oleks, aga igasugune monokultuur ajab mind kergelt leili. Pikemalt räägiti SSL teegist mille nad selle süsteemi jaoks kirjutasid ja proof-of-concept käsurea Jabberi chati kliendist. Kui nüüd tahta sellest chati kliendist sulle saadetud faile salvestada või sellele mingit graafilist UId lisada oledki tagasi vajaduse juures terve suur ebavajalik abstraktsioonide hunnik siiski taasluua. Mingiteks väga spetsiifilisteks asjadeks võib selline lahendus samas isegi sobida.
  • Code Pointer Integrity Ettekanne rääkis kuidas C (ja põhimõtteliselt ka C++) koodi teha automaatselt ründevektoriks olevate mälukasutuse vigade kindlaks (buffer overflowd jms. klassika). Põhimõtteliselt on tehtud LLVM peale vahend, mis analüüsib koodi ja igasugu ohtlikule pointeri aritmeerikale (sellisele mis võib viia control-flow muutmiseni) lisatakse runtime kontrollid. Innovatsioon oligi siin just selles, et ainult tõesti ohtlikele kohtadele lisatakse ainult sellised kontrollid, mille tulemusena on jõudluse kahanemine üldjuhul piisavalt väike (paar protsenti), et seda võiks reaalse süsteemi peal ka tootmises kasutada. Kogu värk on avatud lähtekoodiga saadaval ja pikem jutt toimemehhanismist siin. Nad on kokku lasknud enda vahendiga turvatud FreeBSD kasutajaruumi koos 100 portsuga nii, et peaks olema täiesti reaalselt kasutatav asi, mitte selline akadeemiline veidrus. Üldiselt tundus selline C koodi automaatne töökindlamaks muutmine palju praktilisemat maailma üldist turvataset tõstev asi, kui eelpoolmainitud kõige nullist uuesti kirjutamine.

Valimised

  • Security Analysis of Estonia’s Internet Voting System Vaadeldi igasuguseid elektroonilise hääletuse süsteeme läbi aegade ja nende auke. Alles kuskil keset ettekannet jõuti tegelikult Eesti i-hääletuse süsteemi kirjeldamiseni. Põhikriitika Eesti i-hääletusele oli, et sellise süsteemi ohumudel peaks tänapäeval arvestama riikliku klassi ründajaga, kes on võimeline konstrueerima väga keerukaid ja kalleid rünnakuid. Väide oli, et Eesti ohumudel pigem ei arvesta sellist klassi ründajaga ja et käitusturvalisuses (operational security) oli mitmeid olulisi puudusi.

    Täpsemalt räägiti rünnakust kliendi rakenduse ja serverite vastu. Kirjeldatud rünnakutes ei olnud otseselt midagi uut ja oluline on aru saada, et täielikult turvaline süsteem ei ole võimalik. Seega alati kui arutletakse küsimuse üle, kas i-hääletus on turvaline, on küsimus tegelikult selles, kas nad on piisavalt turvalised. Küsimus taandub sellele, kas ründajale on kasu edukast rünnakust piisavalt suur, et katta kulud (ja ka riskid vahelejäämisel). Haldermanni väide oli, et ühe EU ja NATO liikmeks oleva riigi kontrolli alla saamine võib olla riikliku klassi ründajale piisavalt suur motivaator, et finantseerida väga kalleid ja keerukaid rünnakuid.

    Esimesena kirjeldati valimisrakenduse pahavaraga ründamise võimalust, mis on algusest peale olnud teada ja süsteemi nõrgim koht. Küsimus on pigem, kas seda annab realistlikult teha mastaabis, mis tulemust oluliselt mõjutaks ilma, et pettus seejuures ilmsiks tuleks. Riskianalüüsid paistavad järeldavat, et pigem mitte (kuid jällegi analüüs eeldab põhimõtteliselt siseriikliku rünnet).

    Rünnak serveripoole vastu tundub oluliselt huvitavam, sest kuigi vajalik rünnak on siin palju kordi keerukam ja kallim, on ka potentsiaalne kasu vastavalt suurem – eduka rünnaku puhul valimisserveri vastu võib väljundiks anda ükskõik millise tulemuse. Ühtlasi tundub ühe viimistletud konkreetse serveri vastase rünnaku avastamine ka palju vähem tõenäoline, kui mitmekümne või mitmesajatuhande kliendi arvuti puhul.

    Potentsiaalsete rünnakute kirjeldusele järgnes käitusturvalisuse probleemide loetlemine. Kõige masendavamad tundusid mulle neist:

    • mingi isikliku suvalist tarkvara täis läpaka kasutamine valimisrakenduse allkirjastamiseks
    • tulemuste liigutamine häältelugemisserverist välja isiklikul (igasugu juhuslikku kola täis) mälupulgal (peale seda kui DVD kirjutamine mingil põhjusel ebaõnnestus)

    Järgnevalt kirjeldati eesti poliitikute, ajakirjanduse ja asjaga seotud tehnoloogia ekspertide reageeringut, mis oli üsna masendavalt mustvalge. Tunda on, et osale seltskonnale mõjub igasugune i-hääletuse kriitika nagu isiklik solvang. Teine pool jällegi teeb vastavalt kõik endast oleneva veenmaks rahvast, et e-hääletus on absoluutselt ebaturvaline ja tuleks kogu täiega kaotada.

    Näiteks toodi Rõivase kommentaar, et keegi Haldermani tiimi liige on facebookis mingi linnavalitsuse töötaja sõber ja seega töötab vastasele (klassikaline ad hominem rünnak). Või siis valimiskomisjoni kommentaar, et kui oleks sellise võimekusega ründaja, siis ta ju varastaks pigem raha kui hääli (väga veider eeldus riikliku ründaja puhul). Lõpetuseks näidati veel ka Veldre vastust CERTi nimel pealkirjaga E-valimised on (liiga) turvalised, mis lisaks provotseerivale pealkirjale sisaldab ka samavõrd üle võlli sisu (sarkastilises toonis ja ad hominem rünnakutega).

    Sellised ärapaneva tooniga arrogantsena mõjuvad avaldused tekitavad kõike muud, kui usaldust süsteemi vastu.
    Tehniline vastulause peaks olema võimakult emotsioonitu ja faktiliselt täpne. Ei ole vähimatki mõtet laskuda vaidlustesse kelle mälupulka täpselt kasutati või selle üle kas Halderman ikka suudab 100% kindlalt tõestada, et pokkeri- või torrenti rakenduse ikooni taga tegelikult ka just see rakendus oli.

    Sellise ettevõtmise käitusturvalisus peab olema laitmatu. Igasse kõvalekaldesse peaks suhtuma tõsiselt ja neile järgnema avalik arutelu ja selgelt kommunikeeritud parandus järgnevaks korraks.
    Näiteks mingite isiklike läpakate kasutamise asemel eeldaks ma vähemalt Bruce Schneieri kirjeldatud skeemi, et ostetakse mitu erinevat läptopi erinevatest füüsilistest poodidest ja paigaldatakse neile puhas tarkvara ja rohkem need masinad võrku ei satu.

    Hea algus reaalse usalduse tekitamiseks oleks võtta ette Haldermani artikkel, punkthaaval läbi töötada 3.2 ja 3.3 all toodud märkused, teha vajalikud parandused ja kus vaja endale ka avalikult tuhka pähe raputada.

    Kokkuvõttes tundub kogu vastasseisu põhjus olevat küsimuses, kuhu täpselt tõmmata piisava turvalisuse joon. Halderman ütleb, et realistlik on riiklikul tasemel ründaja, meie enda riskianalüüsid paistavad piirduvat siseriikliku ründaja eeldusega. Rünnakud, mis mõnda aega tagasi tundusid kuuluvat ulmevaldkonda, on tänaseks Stuxneti ja Snowdeni paljastustega saanud reaalsuseks. Seega tundub üsna arusaamatu, miks näiteks Veldre vastulauses selliste rünnakute võimaluse üle ironiseerib (peab sama tõenäoliseks, kui päikese ootamatut kustumist või neutronpommi balti jaamas).

    Mida meie i-hääletuse riskianalüüsid siis täpsemalt ikkagi ütlevad? Ametlik valimiskomisjoni tellitud analüüs aastast 2011 loetleb päris pika rivi mitmesuguseid võimalikke rünnakuid, omistab neile hinnangulised tõenäosused (3 palli süsteemis hinnang) ja pakub mõningaid variante asjade paremaks lahendamiseks. Siit me otseselt teada ei saa, millise ründajaga arvestatakse ja tõenäosused paistavad olevat saadud lihtsalt intuitsiooni pealt.

    Viimastel aastatel on kirjutatud mitu magistritööd, mis üritavad formaalsematel alustel (ründepuudega) i-hääletuse vastastele rünnakutele tõenäosuseid leida. Üks ilus lühike ülevaade kahest sellisest magistritööst Eesti i-valimiste riskianalüüsi teemadel on siin. Seal leitakse muide, et i-hääletuse tühistusrünnak võiks täitsa tasuv ja suhteliselt odav olla ka siseründajale (aga sellistest rünnakutest Halderman ei rääkinud, seega las ta hetkel jääb).
    Ma tahaks tähelepanu pigem juhtida sellele, et selline tasuvusanalüüs ei ütle meile tegelikult midagi riikliku ründaja rünnakute tõenäosuste kohta. Seda kahel põhjusel. Esiteks eeldab mudel, et ründaja on ratsionaalselt ja majanduslikult mõtlev (poliitiliste kaalutlustega ei arvestata ja olekski üsna võimatu arvestada). Teiseks tuleb mudeli kasutamiseks sinna panna mitmesuguseid numbreid, mille määramine riikliku ründaja puhul on pea võimatu. Näiteks, kui palju oleks Venemaa valmis ohverdama, et ühte NATO ja EU liikmesriiki endale sobivat valitsust saada?
    On see miljon, 100 miljonit, miljard või 10 miljardit eurot? Ma ei ütleks, et ükski neist numbritest lähiajalugu vaadates täiesti võimatu oleks.

  • The rise and fall of Internet voting in Norway Norra krüptograaf andis ülevaate Norra i-hääletuse piloodist, mis tänaseks on maha kantud (i-hääletuse pooldajad kaotasid võimu). Norras puudub meie ID kaardiga analoogne süsteem, seega saadeti postiga mingeid paroolikaarte, mis ei kõla just väga turvalise ega elegantse lahendusena. Kogu süsteem olla liiga keerukalt tehtud (mingi 200k+ rida enterprise stiilis koodi) mille turvalisuses on end üsna raske veenda.
    Sellegipoolest oleks ka meil siit üht teist õppida. Esiteks lasid nad häältelugemise rakenduse kirjutada kahel erineval arendajal ja ka kasutasid mõlemat – vaadati, väljund oleks identne. Võimaldab püüda nii vigu kui ka lihtsalt ründaja elu oluliselt raskemaks teha. Teatud kriitilistes rakendustes on selline liiaste süsteemide kasutamine täitsa tavapärane, täitsa nõustun norrakatega, et ka riigi tuleviku otsustamine võiks sama oluline olla.

    Teine teema oli protsessi läbipaistvus, väidetavalt oli kood githubis kõigile nähtav ja auditeeritav. Eestis näiteks on kliendirakenduse kood kinnine (nagu ka mingid jupid serveripoolsest otsast).
    Ka kole avalik kood võimaldab mingi seisukoha kujundada, kinnise koodi usaldamine on paraku puhas usuküsimus. Mina isiklikult security by obscurity usku ei ole.

Krüpto / privaatsus

  • ECCHacks – A gentle introduction to elliptic-curve cryptography Lihtsate ja arusaadavate näidetega sissejuhatus elliptilistesse turvakõveratesse koos Pythoni koodinäidetega. Ilmselt kui veel mingi 3-4 korda vaatan saan päriselt ka aru 😛 Seletatakse muuhulgas, miks konkreetsete sobivate kõverate valik on nüansrikas ja miks NSA või kellegi teise poolt arusaamatutel alustel valitu võib olla väga hea ründevektor.
  • Finding the Weak Crypto Needle in a Byte Haystack Räägiti kuidas võtme taaskasutust automaatselt tuvastada. Minu jaoks põhiväärtus tegelikult esimeses pooles, mis räägib mis on võtme taaskasutus ja miks see halb on koos praktiliste näidetega.
  • Forging the USB armory Räägib USB pulka mahutatud pisikesest personaalse turva otstarbelisest arvutist. Saab kasutada asjadeks nagu bitcoini rahakott, krüpteeritud andmesalvestus, paroolihaldus, VPN, ssh gw. jne.
  • Now I sprinkle thee with crypto dust Väga intensiivne ülevaate ettekanne, kus tunni aja jooksul mitmed projektid räägivad 10-15 minutit oma projektist. Ühendavaks jooneks nende projektide vahel on soov teha internet turvalisemaks, raskemini tsensuuri poolt kontrollitavaks ja pealtkuulamiskindlamaks. Minu jaoks neist kõige meeldejäävam oli viimasena kirjeldatud Darkmail projekt, mis on katse teha otspunktkrüpteerimisega (end-to-end encryption) e-maili lahendus. Erinevalt varasematest sama eesmärgiga lahendustest (GPG) on seekord plaan teha asi, mida oleks lihtne kasutada ja oleks lõppkasutaja jaoks üsna nähtamatu.
  • UNHash – Methods for better password cracking Kirjeldas avatud lähtekoodiga rakendust inteligentseks paroolide äraarvamiseks (vastandina tavapärasele jõumeetodile). Põhimõtteliselt on erinevate lekkinud suurt paroolibaaside pealt kirjeldatud mustrite klassid, mille alusel inimesed tihtipeale paroole koostavad (stiilis <number><sõna><number>). Paljud näiliselt keerukad ja pikad konstruktsioonid (näiteks paroolifraasid) on sellise meetodiga väidetavalt palju lihtsamini murtavad, kui klassikaliste vahenditega.
  • DP5: PIR for Privacy-preserving Presence Räägiti, kuidas teha homomorfse krüpteerimisega privaatsust säilitavaid andmebaase olemasolu (presence) teenuse näitel. Selline lahendus võimaldaks luua põhimõtteliselt igasugu suhtlusvõrgustikke ja sotsiaalseid võrkke, kus teenusepakkuja ei oma mingit ülevaadet kes on kelle sõber ja kellega suhtleb. Seletatakse üsna hästi ära, kuidas homomofrne krüpto töötab ja tavainimesele kordaminevat rakendust selle peal. Fundamentaalseks probleemiks tundub olevat süsteemi skaleeruvus kasutajate arvu lisandudes süsteemi (tegelikult baasi suuruses lihtsalt küsimus). Toodi näide, et miljoni kasutajaga privaatse võrgu puhul on käigushoidmise kulu kuskil 1$ kasutaja kohta kuus.

huumor

  • Internet of Toilets Andis ülevaate erinevatest WC automatiseerimise projektidest (peamiselt DIY) asjad. Huvitav oli üsna lõpus mainitud tõsiasi, et on olemas esimesed exploidid tarkadele WC pottidele, mis võimaldavad ründajal prill lauda tõsta-langetada, veejuga lasta jne.
  • Funky File Formats Väga humoorikas ja samas tehniliselt hariv ettekanne, mis rääkis milliseid trikke on võimalik failiformaatide veidraid võimalusi kasutades teha. Näiteks alustati jpg failiga, mis ühtlasi on täiesti legaalne ja toimiv Java jar fail. Kui algne JPG fail AESiga krüpteerida saadi tulemuseks hoopis teist pilti sisaldav PNG fail, 3DESiga lahti krüpteerides on tulemuseks PDF jne. Või siis PDF fail mida eri rakendustega vaadates näeb kardinaalselt erinevat sisu ja printer prindib välja hoopis kolmanda sisu.
  • Computer Science in the DPRK Põhja korea IT ülikoolis õppejõuna töödanud ameeriklane rääkis kuidas seal riigis on lood ITga. Humoorikas moment oli siin peamiselt nende riiklik operatsioonisüsteem Red Star. Tegu on Linuxiga, mis nii välimusest kuni failisüsteemi paigutuseni on aetud nii Applei OS X sarnaseks kui võimalik.

RTK GPS base station

As I mentioned in an earlier post, Skytraq released a cheap GPS board that is able to output raw measurements. That makes it suitable for use with RTKLIB and allowed me to build my own stationary GPS base station for around 150€. This is a quarter of the cost of the previous cheapest solution I had found and only a small percentage of the price that one would pay for a commercial RTK base station.

RTK GPS basestation

RTK GPS basestation controller

and closeup of the antenna (Satmar-FME):
closeup of the GPS antenna

I will write another post describing how accurate this setup is once I have had a chance to test it better.

configuring a fake mail server for testing

When building systems that send out e-mails to the customers one has to find a way to test what the output looks like without actually sending the mail to the client.

This article describes how to set up such a fake mail server that can be used in the test environment as a drop in replacement for you actual mail gateway.
Incoming e-mails will be stored on the local inboxes based on the FROM address (the TO address is ignored).
This allows you to test multiple applications against the same test mail server assuming that the applications use different FROM address.

I will also show how to configure IMAP access to these test mailboxes.
This guide has been tested on Debian 7.

Postfix

We will use Postfix as our SMTP server and Dovecot for the IMAP support.

apt-get install postfix dovecot-imapd

In the file /etc/postfix/master.cf find a line that looks like this:

smtp      unix  -       -       -       -       -       smtp

and replace it with:

smtp      unix  -       -       -       -       -       discard

This tells Postfix to send all outgoing mail to discard instead of smtp.
discard will just happily accept whatever is sent to it and will always report successful delivery.

In order to keep a local copy of the the discarded mail for testing add the following line to the file /etc/postfix/main.cf:

sender_bcc_maps = hash:/etc/postfix/sender_bcc

This parameter tells where BCC copies of the mails should be sent based on the FROM address.

Create the /etc/postfix/sender_bcc with contents like this:

user@example.com test1@fake
@example.com fallthrough@fake

and run the command:

postmap /etc/postfix/sender_bcc

At this point the very basic setup is in place and if you restarted the postfix all the relayed e-mails would be dropped and local copies would be stored in mailboxes under /var/mail

To make testing a bit more convenient we will set up virtual mailboxes that will be stored under /var/vmail and can be accessed over IMAP using non-system accounts.

Add the following to the file /etc/postfix/main.cf:

virtual_mailbox_domains = fake
virtual_mailbox_base = /var/vmail
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:65534
virtual_gid_maps = static:8

Create the file /etc/postfix/virtual_mailbox

test1@fake test1/
fallthrough@fake test2/

Run postmap on it:

postmap /etc/postfix/virtual_mailbox

Create the mail directory:

mkdir /var/vmail
chown nobody:mail /var/vmail

Now restart Postfix.

postfix reload

At this point mail should be correctly be delivered to Maildir formated directories under /var/vmail for addresses that match entries in /etc/postfix/sender_bcc.

IMAP

Now we will configure access to these local mailboxes over IMAP using Dovecot.
We will use file based auth to keep things as simple as possible.

Create the file /etc/dovecot/conf.d/auth-plain.conf.ext with the following contents:

passdb {
  driver = passwd-file
  args = username_format=%u /etc/dovecot/passwd
}

userdb {
  driver = passwd-file
  args = username_format=%u /etc/dovecot/passwd
}

Now open /etc/dovecot/conf.d/10-auth.conf and add the following line at the end of it:

!include auth-plain.conf.ext

Create the file /etc/dovecot/passwd with contents similar to this:

test1@fake:{SSHA}ghZpew7L4psekJyC0MUoVA3Usg0SxAjm:65534:8::/var/vmail/test1::
test2@fake:{SSHA}c9yb4ibK+rpoMBR+OnoMBrNgyjD8KraL:65534:8::/var/vmail/test2::

Password hashes can be created with doveadm like this:

doveadm pw -s SSHA -p yourPassword

Edit the file /etc/dovecot/conf.d/10-mail.conf by replacing

mail_location = mbox:~/mail:INBOX=/var/mail/%u

with

mail_location = maildir:/var/vmail/%n

Finally restart Dovecot with:

/etc/init.d/dovecot restart

Safeguard

To make double sure that no test e-mails will leave this system we will also firewall outgoing SMTP and only allow connections over localhost:

iptables -A OUTPUT -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j DROP

And to make this change permanent add it into the file /etc/network/interfaces so that it would be read in every time the interface comes up. Mine looks like this:

iface eth0 inet dhcp
        up /sbin/iptables -A OUTPUT -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
        up /sbin/iptables -A OUTPUT -p tcp --dport 25 -j DROP

cheap RTK-GPS hardware might soon be available!

As mentioned previously I used two loaned u-blox LEA-6T devkits for my robot mower prototype which seemed to get acceptable precision (~10-20cm) with RTK-GPS using RTKLIB. Problem with this solution was that these devkits cost around 300 EUR which is far too much for my intended usage.

Until now I planned to switch to Yuan 10 for the next prototype. Yuan 10 costs 97.60 per board (antennas not included) and uses SkyTraq S1315F-RAW chip internally which is able to output raw measurement at 5Hz.

It turns out though that there is currently an NavSpark fundraising campaign by the SkyTraq itself which, if sucessful, will get you 2 boards with this chip + active antennas for 50$. At the moment of writing more than half of the campaign time has passed and they are less than 30% funded so if you want cheap RTK-GPS to happen support them and spread the word.

Getting such an high precision GPS solution for so cheap would certainly open many new interesting usage possibilities!

PS. This RTKLIB compatible perk was actually added quite late to their project. Main goal is to produce tiny sub 20$ GPS boards that can be programmed, run at 100Mhz and have lots of usable GPIO pins, which is also awesome.

quick and cheap RFID with RPi and rc522

To my great surprise it turns out you can nowadays get an RFID reader with 2 tags for somewhere between 7$ and 10$. Better yet, interfacing these to Arduino is well documented and several libraries are available for that purpose.

My friend who bought a couple of these asked me to see if I can read the tags directly from a Linux based ARM board (for example Raspberry Pi). It turned out to be rather easy as long as you aren’t interested in anything but the ID of the card. This can be done using rpi-rc522 library (NOT written by me). It sadly currently lacks any documentation or a Makefile so here are my notes on how to get it running.

First you have to connect the rc522 and RPi over the SPI interface. It will look something like this:

Raspberry pi and rc522 RFID reader

Raspberry Pi and rc522 RFID reader

Then you have to install the bcm2835 library. Assuming that you have gcc and other essential development stuff already installed you can achieve it this way:

wget http://www.airspayce.com/mikem/bcm2835/bcm2835-1.35.tar.gz
tar -zxf bcm2835-1.35.tar.gz
cd bcm2835-1.35
./configure
sudo make install

After that you can compile and run the rpi-rc522 with the following commands:

sudo apt-get install subversion
svn checkout http://rpi-rc522.googlecode.com/svn/trunk/ rpi-rc522-read-only
cd rpi-rc522-read-only/rc522
gcc config.c rfid.c rc522.c main.c -o rc522_reader -lbcm2835
sudo cp RC522.conf /etc/
./rc522_reader -d

You should see tag IDs in the output of the program as they are read. You can put these into the /etc/RC522.conf file and map each ID to a specific command to run there.

measuring power usage

Today I discovered that the ethernet port on my beaglebone white that I used as a home automation controller had died. Luckily I had a new beaglebone black at hand. Since several people have asked about my automation stuff I decided to take a couple of pictures while replacing the controller.

In general my breaker box looks like this:
breaker box

The energy meter in the top left corner is mine so I could just connect beaglebone to its counter pins directly instead of reading it from the IR diode. Beaglebone black is the thing with blue leds in the bottom left side of the picture. The energy meter basically has a switch that “connects” the attached wires 1000 times for every kWh consumed. So measuring the energy usage is just a simple matter of configuring one of the beaglebone’s IO pins for input and poll()’ing for the changes.

beaglebone_resized

The protoboard + arduino combo to the left of the beaglebone is used for listening in on my house alarm system bus (DSC 5010). I haven’t yet reconnected it. To the right of the beaglebone you can see the cable modem that I use to connect this thing to the router on the second floor. Wifi would have been easier but doesn’t work well in the basement, coaxial cables happened to be present and I got some old cable modems for free.

Beaglebone also serves a simple web frontend with statistics for all the sensor feeds that it records. For example the energy usage overview looks like this:
energy usage

I currently use PostgreSQL as my data store and I have been seriously impressed with its ability to run on such a weak hardware. When I was using beaglebone white that only had 256MB of RAM, with class 4 SD card I actually only used raw measurements table that stored data for all my datasources with 1 minute precision. This table had 2.5 million rows and still managed to answer complex aggregate queries for energy usage (N last days, group by day and each day by day and night) in about 5 seconds. Now that I have added hourly aggregated table it’s back to about 0.1s.

PS
I also moved to a newer kernel (3.8.13) where the old omap_mux sysfs hierarchy is gone so it took me a bit of time to find how to configure the pins under the new world order.
It turns out to be rather logical (besides the pin numbering part :-P) so in order to configure pin 12 on P9 header as an input I had to do this:

echo 60 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio60/direction
echo falling > /sys/class/gpio/gpio60/edge

500 eggs later

This spring we bought 5 young Indian Runner ducks: 4 female ones and 1 male one. The ducks are called Termitomyces, Concepcion, Diversant and Part; the drake is called Tutulus. Today we had our 500th egg and we probably won’t get many more this year since the temperatures will soon be below freezing point and some have already stopped laying.

ducks

I wanted to write down a couple of things that we have learned about duck keeping during our first year. Maybe it will help someone.

First of all I live in Estonia which has a rather cold climate. For 3-5 months per year we have thick snow and the temperature is below freezing. Sometimes it’s around -20C for a week or even longer. While ducks are hardy and don’t seem to mind bitter cold they still need something that protects them from the wind, drinking water and some water to clean themselves in.

Luckily we didn’t have to start from zero since we already had an ex-henhouse on our property from the previous owners.

duckhouse

It stands on 4 drystone pillars about 1m above the ground, measures 4x4m and has the roof and walls covered with tin roofing panels and has mains power available.

duckhouse closeup

So in short it’s a total overkill for this particular purpose. In the spirit of overkill I built a porch for it with a rather long ramp in place of the stairway since ducks can’t climb stairs as well as hens do. We also bought a large fishing net that protects some of the duck yard from goshawks and other flying predators since they were the reason why the old owner stopped keeping birds. Ducks also like to sleep under
the house during warm summer days which protects them nicely from overheating and flying predators.

The main problem with keeping ducks indoors for a large part of the year is that they are really messy birds and like to play with water. In the beginning we just had a ~15l water bowl in the middle of the room that they drank from and used for washing. We filled the bowl in the morning and in the evening and in between they always managed to find a way to spread most of it all over the room. This can’t possibly be good for the wooden floor of our duckhouse so we tried various ways to reduce the splatter.

What we are currently using is a balconly flower pot that is attached to the wall ~5cm from the ground and everything near it is covered with linoleum. Directly under the flower pot we have a large plastic multipurpose tray that has 4cm high edges. That way most of the splatter will stay on the tray that we can easily clean.

drinking ducks

Skepticism @ Padise

I was at the Skepticism, Thou Shell of Death and Forgotten Sunrise gig in the ruins of Padise Monastery in Estonia yesterday (28.09.2013) . Considering that Skepticism seems to perform live only once every couple of years or so it was extremely surprising to see them perform so close to me.

Anyway the atmosphere of the monastery ruins is an extremely suitable place for listening to a good funeral metal band and at almost 2 hours the Skepticisms gig was longer than the previous ones I have been to. Aside from a couple of people constantly chatting, yelling and whistling in the front row there was nothing to complain about. The sound and the performance by Skepticism were just perfect.

The best that I could capture with my N900 is this:
20130928_skepticism

You can probably find much better pictures of the event from its Facebook page.

As a (lousy) guitarist I was very interested in how exactly does Skepticism achieve such a nice thick sound that sometimes sounds like they have 2 guitars playing so I took a picture of the guitarist’s rig:

20130928_skepticism_guitar_rig

The bottom row of pedals from left to right is:

  • Boss FV-50 volume pedal
  • Electro Harmonix Metal Muff (distortion)
  • Morley George Lynch Tripler Pedal (3 way output splitter)
  • Boss Metal Zone (distortion)
  • Boss Metal Core (distortion)

The single smaller pedal in the center seems to be some kind of Korg tuner since there’s nothing coming out of it. Can’t find an exact match though.

The first and the third channel of the Tripler splitter are active. Metal Muff is connected to the first channel and the two Boss distortions are connected to the third channel in series (probably not used at the same time). The second channel of the splitter is inactive and connected to the Korg tuner.

So to make the long story short the thick guitar sound seems to be achieved by using two different distortions on different amp channels in parallel.

another iteration of the bot

I did a bunch of hardware modifications to my bot over the weekend to make it more sturdy and to get rid of most of the loosely connected wires and the separate proto board. This is what the current iteration looks like:
ukerdis_rev_03

The main changes are:

  • 5Ah Li-ion battery replaced with two 4.6Ah NiMH batteries connected in parallel because for me the relative safety of the NiMH outweighs the capacity/weight gains of the Lithium based chemistries. I really don’t want to worry about my house burning down while charging the battery packs.
  • Replaced the Wifi dongle with a far smaller one. The new dongle is using Realtek 8192cu chipset which isn’t supported out of the box as well as the old Atheros based dongle was but I think I got it working reasonably well in the end.
  • Replaced the older generation BeagleBone with Beagle Bone Black (BBB).
  • Moved the bidirectional level shifter that is used for serial communication between the Wild Thumper Controller and BBB from separate proto board to BeagleBone proto cape.
  • Changed BBB’s power supply from 1.5A Recom 78b5.0-1.5 to 3A BEC. This change was actually done because the 3A BEC comes in a nice discreet package which is already more or less protected from the environment and having more power available is just a nice side effect.

With that the platform is stable enough that I can actually concentrate on the navigation. On that front I set up an RTK-GPS solution with RTKLIB and couple of borrowed u-blox LEA-6T evaluation kits.
This is how my ad-hoc base station looks like:
gps_base_station_1024

This is what the signal levels look like in RTKNAVI:
rtklib1_nocoord

To get a good set of waypoints for testing the robot I walked a couple of times up and down my driveway:
rtkplot showing me walking up and down the driveway

The yellow dots show the FLOAT solution and the green ones show where I had the FIX solution. Basically getting the FIX solution is more precise and means the calculations that RTKLIB does, lead to a single unambiguous solution at these points.

Zooming in we can see that the points from different times are at most about 20cm apart which is really good considering that I was just trying to walk in the track of the car wheel and certainly veered off a bit at times.
RTK solution closeup

two steps forward one step back

I spent most of today working on my autonomous lawnmower project. What I currently have is this:

robot_from_the_back_1024

The main changes from the last prototype are the plywood box around the cutting motor and the relocation of the motor controller board to a higher place where there’s more room and less chance of getting covered with wet grass. I also switched the main controller board from Nokia N900 to Beaglebone since I had a bit of trouble getting USB host mode & WIFI working together in a stable manner on the N900. Sadly I managed to fry my Beaglebone Black so I’m currently using an older generation Beaglebone that has so far served as my main automation controller.

There are still far too many fragile loosely connected wires all over the place and if you look carefully there’s actually even a breadboard so I still have a lot of work to do before it’s ruggedized enough for its intended purpose.