Bluetoothsäkerhet<br>- implementering

Säkerhet har varit viktigt för Bluetooth Special Interest Group (BSIG). Även om bluetooth i sig är en mycket säker teknik, och specifikationerna ger allt som krävs för att en utvecklare ska kunna sätta samman en säker bluetoothprodukt, så är en kedja inte starkare än sin svagaste länk. En bluetoothprodukt är säker bara om den som ska implementera tekniken använder alla säkerhetsfunktionerna på ett korrekt sätt. Oriktiga konstruktioner kan göra en bluetoothprodukt osäker och få en användare att tvivla på teknikens säkerhet. Den första delen av denna artikel beskriver säkerhetsfunktionerna hos enskilda bluetoothkomponenter, och följande avsnitt går in på de olika komponenterna och förklarar de olika typerna av brott mot bluetoothsäkerheten och rekommenderade lösningar för att förhindra att produkternas säkerhet riskeras. Säkerhet hos individuella moduler Bluetoothkomponenter är vanligen integrerade, och inte implementerade från start. Tvåchipslösningen, den värdbaserade lösningen, är vanlig i många produkter, och den visas i figuren nedan. Figur 1: Host-Stack arkitekturen För att bygga en heltigenom säker produkt måste de integrerade enskilda komponenterna vara i enlighet med lämpliga säkerhetskrav. Följande tabell ger information om säkerhetsegenskaper och –funktioner hos enskilda komponenter: Säker användning av produkten är användarens ansvar, men en bra tillämpning bör ge användaren stöd så att denne inte oavsiktligt använder produkten på ett osäkert vis (till exempel genom att tillämpningen har en lämplig markering genom varningssignaler eller –toner när användaren är på väg att göra någonting som kan vara osäkert.) Låt oss titta närmare på hur produktapplikationen kan implementeras på ett säkert sätt genom ett exempel på en produkt. Säkerhetsöverväganden i en produktapplikation Vi ska titta på en handsfree bilutrustning: de säkerhetsattacker den kan utsättas för, och hur dessa kan förhindras i implementeringen. Handsfree-enheter stöder funktioner som hantering av inkommande samtal eller streaming av musik. De funktioner som vanligen krävs för att förverkliga dessa egenskaper är: - HF (Hands-free Profile)/HS (Headset Profile) - OPP, (Object Push Profile) och/eller PBAP (Phonebook Access Profile) - A2DP (Advanced Audio Distribution Profile) och AVRCP (Audio Video Remote Control Profile) Några av de säkerhetsattacker som en handsfreeutrustning kan utsättas för är: (i) Avlyssning eller "Bilviskare" (ii) "Bluejacking" (iii) Stöld av data i adressboken Låt oss anta att vi har att göra med en sofistikerad hacker, som har en air sniffer, PC-baserade verktyg, en antenn som låter sig riktas för att öka räckvidden, och som också kan följa efter bilen i hög hastighet! Det minimum av information som hackern måste känna till för att komma åt handsfree-enheten är dess BD_ADDR. Ett scenario för hackern är att han hittar BD_ADDR när handsfree-enheten är i synligt läge. Då behöver hackern bara göra en sökning för att hitta enheten. Från namnet på de synliga enheterna kan hackern ofta ganska enkelt gissa sig till vilken enhet det rör sig om. Det har varit ett misstag som begicks av de tidigare implementeringarna att alltid ha enheten i synligt läge. Men de nyare tillämpningarna ser till att bara ha synligt läge på när det behövs. Riktlinjer för en produkt som en handsfree-enhet skulle vara: - Enheten ska inte vara synlig direkt vid starten - Enheten måste ställas in i synligt läge (”hopparbart”/pairable läge som det kan stå på displayen) av användaren för att kopplas samman med en annan telefon för första gången. - Hopparning måste genomföras i en säker miljö, eftersom de uppgifter som skickas skulle kunna användas för att räkna ut länknyckeln. Användaren måste genom en lämplig varning på skärmen och ljudsignaler göras uppmärksam på att hopparning bara kan genomföras i en säker miljö, som användarens hem eller garage. - Efter en genomförd hopparning måste enheten kopplas ifrån synligt läge och bli möjlig att ansluta till, så att endast en ”känd” enhet kan ansluta sig till den. - En timeoutperiod kan ställas in, vilket innebär att om hopparningen inte lyckas inom en viss tid, så kopplas det synliga läget ifrån automatiskt. Användaren måste själv ställa in enheten i hopparningsläget för att den ska kunna kopplas ihop med en annan enhet. - Antalet försök till hopparning kan också anges. Figur 2 förklarar hur hopparningssekvenserna ser ut vid första hopparningen, och figur 3 beskriver autentiseringssekvensen för nästa förbindelse mellan handsfree-enheten och mobiltelefonen. Figur 2: Autentisering under hopparning Figur 3: Autentisering under förbindelse efter första hopparning Låt oss titta närmare på ett annat extremt exempel på ett säkerhetsbrott med bluetooth. Trots att användaren har följt riktlinjerna ovan, så har hackaren lyckats få tag i handsfree-enhetens BD_ADDR på något sätt (vi kan anta att hackerns enhet vid något tillfälle hade blivit hopparad med handsfree-enheten, men att den inte längre finns på enhetens lista över tillförlitliga enheter.) Låt oss så titta på hur man förebygger de olika typerna av attacker i ett sådant fall. (i) Avlyssning/”Bilviskare” Det fall vi beskrev i artikelns inledning är just ”bilviskaren”. Kan någon få oauktoriserad tillgång till bilens högtalare? Ja. Bara om hackern känner till: - Handsfree-enhetens BD_ADDR - Den PIN-kod som handsfree-enheten använder Möjlighet 1: Hackerns enhet hade blivit hopparad med handsfree-enheten vid något tidigare tillfälle, men finns inte längre med på enhetens lista över tillförlitliga/hopparade enheter, men ändå känner hackern fortfarande till handsfree-enhetens BD_ADDR och PIN-kod. Lösning: - Använd inte samma PIN-kod hela tiden. Generera en slumpmässig PIN-kod (som användaren ser i sin display) för varje hopparningssession, eller låt användaren registrera en egen PIN-kod (till exempel genom röstigenkänning). Möjlighet 2: Hackern känner till enhetens BD_ADDR, men inte dess PIN-kod. Eftersom många tillämpningar använder sig av en ”standardkod” som 0000 eller 1234, så kan hackern enkelt gissa sig till den. Oftast har alla produkter av samma märke samma PIN-kod, så hackern behöver bara känna till handsfree-enhetens tillverkare! Lösningar: - Använd inte en standardkod. Generera en slumpmässig PIN-kod för varje session, eller låt användaren knappa in sin egen PIN-kod. - Tänk ut ett sätt att massproducera produkter med en unik PIN-kod för varje enskild enhet. Den unika koden kan tryckas på förpackningen. - Tillåt bara att en enda enhet är uppkopplad åt gången. Om användarens enhet redan är ansluten till handsfree-enheten, så skulle det då inte vara möjligt för hackern att ansluta sin enhet också. Kan någon avlyssna ett samtal på handsfree-enheten? Ja, om hackern: - Har en air sniffer - Känner till handsfree-enhetens BD_ADDR När hackern känner till BD_ADDR kan han helt enkelt använda en air sniffer för att fånga upp alla signaler i luften till och från handsfree-enheten, och kan få fram ljuddata från SCO packet (detta är lite förenklat, men möjligt för en kunnig hacker med rätt utrustning). Ett bra sätt att undvika detta är att ha obligatorisk kryptering. All kommunikation mellan handsfree-enheten och mobiltelefonen skulle vara krypterad. Hackern, som fångar upp de krypterade signalerna, behöver en krypteringsnyckel för att knäcka koden. En av de faktorer som genererar krypteringsnyckeln är länknyckeln som används mellan handsfree-enheten och mobiltelefonen. Med utgångspunkt från de signaler som har fångats upp under autentiseringsprocessen(se Figur 3, Autentisering under förbindelse efter första hopparning), då förbindelsen etableras, är det mycket svårt (men inte omöjligt) att beräkna länknyckeln. (ii) Bluejacking Skulle vi nu se den omtalade ”bluejackingen” (http://en.wikipedia.org/wiki/Bluejacking) på handsfree-enheter? Denna attack bygger på att man skickar ett oönskat meddelande, förklätt som en kontaktfil, genom användning av OPP. Handsfree-enheter stöder OPP för att ta emot kontaktuppgifter från mobiltelefoner, och lagras lokalt för att låta användaren ringa upp någon i telefonboken under körning utan att behöva ta fram sin mobiltelefon. Bluejacking är mer ett irritationsmoment än en allvarlig säkerhetslucka. Låt oss anta att hacker på något sätt har kommit över handsfree-enhetens BD_ADDR. Hackern kan då helt enkelt använda ett PC-baserat verktyg för att skicka en kontakt över OPP till handsfree-enhetens BD_ADDR. Detta problem kan undvikas genom att man gör något av följande: • Genom att använda Security Mode 3 eller Security Mode 2 med krav på autentisering för OPP-tjänster. I dessa fall genomförs en autentisering för varje kontakttillfälle. Detta kräver att den som skickar kontakten måste knappa in PIN-koden första gången, och de senare gångerna genomförs autentiseringen av länknyckeln som beskrivet i figur 3. Detta alternativ tar längre tid, och behöver inte upplevas som något positivt av användaren. • En annan möjlighet är att tänka igenom hur applikationerna används, så att användaren till exempel bara skulle ringa upp en kontakt från sin mobiltelefon, som också skulle användas för handsfree-enheten. Därmed borde mobilen redan ha parats ihop med handsfree-enheten, och då borde applikationen bara behöva tillåta kontakter från en enhet som har parats ihop med handsfree-enheten, och helt enkelt avvisa OPP-anslutningar från andra enheter. (iii) Stöld av data i adressboken Handsfree-enheter har en lokalt lagrad adressbok som laddas ner från användarens mobiltelefon. Kan en hacker komma åt denna känsliga information? Låt oss anta att hackern på något vis har kommit över handsfree-enhetens BD_ADDR och helt enkelt kan sända ut en OPP PULL-förfrågning. Följande överväganden kan hjälpa en utvecklare att undvika detta: • Måste adressbokens PULL-funktioner stödjas av handsfree-enheten? Om det inte krävs, kan man då inte bara avvisa alla sådan PULL-förfrågningar? • Om denna funktion krävs (låt oss anta att användaren har blivit av med all data på sin mobiltelefon och vill föra tillbaka data från handsfree-enheten till sin mobil), kan man inte göra om den till en användarinitierad PUSH-funktion istället för en PULL? För att sammanfatta kan en handsfree-enhet skyddas mot säkerhetsattacker genom att följa några regler vid implementeringen av produkten: • Handsfree-enheten ska kunna ställas in i synligt läge endast genom användarens aktivitet när det behövs. • Istället för standardkoder bör man använda slumpmässigt genererade PIN-koder (olika för varje hopparningssession). Överväg lösningar som en användarspecificerad PIN-kod, eller en unik PIN-kod för varje enhet av samma märke. • De specifika exemplen på användning kan ofta ge uppslag för en säker implementering. För vår diskussion har vi använts en handsfree-enhet i bilen som ett exempel. De angivna riktlinjerna gäller även för andra slag av produkter, som till exempel bärbara datorer, headsets, mobiltelefoner. Girish Managoli, MindTree Ltd. Girish Managoli är Technical Manager vid MindTree Ltd. – en global organisation för utveckling av IT-tjänster och R&D som ger kunder stöd rörande förverkligandet av produkter. Inom MindTree ansvarar Girish för anpassningen av MindTrees produktfärdiga bluetoothsvit (EtherMind) till kundplattformar och produkter. Girish har en ingenjörsexamen från University of Mysore i Indien.