Kryptoblog

Bloggaren Albert Veli har skrivit ihop en fin analys av hur bank med en så kallad säkerhetsdosa fungerar. Albert skriver:

De senaste dagarna har jag funderat och läst på lite om säkerheten hos bankernas säkerhetsdosor (eng. digipass). Den första banken jag kollade var Swedbank och säkerheten hos deras dosa var inte tillfredsställande.

Albert fortsätter sedan med en genomgång hur säkerhetsdosan arbetar för att utifrån bankens utmaningar den kundspecifika dosan genererar autenticieringskoder

Alberts analys bygger på den öppna information som finns att tillgå. Jag vet faktiskt inte om det stämmer att Swedbanks säkerhetsdosor använder gammal (obsolet) DES. Det jag vet är att de dosor från Vasco som SEB kör med använder 3DES, och det gör att den typ av attack som Albert tänker sig blir praktiskt sett omöjlig.

Dock pekar Albert på ett generellt problem: Om den privata nyckeln kommer ut är alla koder som den specifika dosan kan generera oanvändbara. Samtidigt är det svårt att se hur man enkelt skall kunna byta ut kundernas privata nycklar. Att helt enkelt spärra bort den specifika dosan och skicka kunden en ny är nog det enklaste.

Riksrevisionen har granskat Svenska myndigheters arbete med IT-säkerhet. Resultatet är inte så lysande:

Riksrevisionen bedömer att de ovan beskrivna problemen är allvarliga och
att de innebär risk för betydande negativa konsekvenser för statliga åtagan-
den som elektronisk förvaltning och nationell krishantering.

Med tanke på de senaste händelserna verkar Riksrevisionen ha rätt. Vill du veta mer kan du läsa Riksrevisionens rapport.

Jag sprang på en tidning på nätet om säkerhet som jag tycker verkar mycket intressant.

(IN)SECURE Magazine är en on-line tidning som ser ut att komma ut med 4-6 nummer per år beskriver sig själv som:

(IN)SECURE Magazine is a freely available digital security magazine discussing some of the hottest information security topics. It can be distributed only in the form of the original non-modified PDF document.

Tidningen ges ut av företaget HNS Consulting Ltd. Senaste numret (nr 11) innehåller bland annat artiklar om

• Elektroniska pass.
• Brandväggen IPtables
• Reseportage från Blach Hat Briefings 2007

Jag tycker det verkar vara en seriös och välskriven tidskrift väl värd sitt pris.

KTH-forskaren Stefan Görling har fått en rapport om Sender Policy Framework (SPF) publicerad i Internet Research. Stefans rapport An Overview of the Sender Policy Framework (SPF) as an anti-phising mechanism innehåller en relativt detaljerad genomgång av SPF. Rapporten går bland annat igenom bakgrunden till SPF och tar även upp alternativa tekniker till SPF, exempelvis S/MIME och OpenPGP. Rapporten presenterar även resultatet av den undersökning Stefan genomfört som visar hur stor spridning SPF har i dag. Stefan skriver:

The analysis showed that the adoption ratio is extremely low. Among the 385,862 domains, only
1.63% (6,286) of all domains have a published SPF policy. Counting only domains having active
mail settings (330,163 domains with MX records), SPF usage ratio is 1.9%

Out of the identified SPF records, 54.5% (3,430) of them contained only the minimal catch-all rule
(“v=spf1 ?all”) specifying that domain has no policy. This policy is basically useless. (12.3%) 775
domains contained the softfail catch-all rule (“~all”), a state between valid and failed where
unidentified sender is unlikely to be authorized, but that we are not sure enough to drop the
message. A state which may be useful when testing a new policy.

Trots denna låga användningen anser Stefan att IS/IT-ansvariga bör överväga att implementera SPF:

However, as long as they recognize the limits and properties of this standard, the creation of a SPF-
policy is desirable. Each new published policy helps the standard to become more widely used and
raises security at least for some users. SPF is available, it is ubiquitous and it is easy to adopt. There
already exist several major anti-spam software vendors with implemented support for this standard
in their products. Simply by publishing a SPF policy, the impact of phishing attempts in your name
will decrease.

Jag vet inte riktigt vad jag skall tycka om SPF. Det är ett enkelt steg att komplettera sin DNS-post med ett vettigt SPF-fält. Frågan är dock hur många som behöver göra det för att det skall bli användbart och ge något. Och frågan är dessutom om det inte krävs DNSSEC för att göra SPF pålitligt som autenticieringsmekansim. Vad tror du?

Enligt en artikel på EE Times har NIST nu publicerat den slutgiltiga versionen av sin rapport om RFID jag tidigare bloggat om. NIST rapport tar upp ett stort antal säkerhetsaspekter kopplade till RFID. Enligt NISTs huvudförfattare till rapporten, Tom Karygiannis, är syftet med rapporten:

The goal of our report is to give organizations practical ways in a structured format with checklists and specific recommendations to address potential RFID security risks.

Rapporten på 100+ sidor är väl värd att titta igenom för att alla som arbetar med RFID.

På Oreillys utmärkta ONLamp finns många bra artiklar. En artikel som måhända inte är purfärsk, men väl värd att läsa är en artikel om hur du automagiskt säkerhetstestar dina webbapplikationer. Artikeln tar avstamp i att dagens webbplatser, ex en webbshop oavsett om den bygger på ASP, .Net eller LAMP är ett komplext system med flera servrar och lager av kod. Att manuellt sitta och leta efter problem blir då ohållbart. Vad som krävs är istället någon form av automatik som gör det möjligt att regelbundet undersöka sitt system. Systemet som artikeln utgår från ser ut så här:

Utifrån detta skapas ett attackmodell med olika typer av attacker mot systemet:

Attackerna kodas sedan upp i ett ramverk som sedan driver ett testsystem byggt i Python som testar systemet och utvärderar responsen från systemet. Ett slags black-box-testning helt enkelt.

Det jag saknar från artikeln är ett påpekande om att detta försfarande inte bara är applicerbart på befintliga webbplatser, utan naturligtvis borde användas både vid system- och applikationsutvecklingen under utvecklingsfasen samt under systemets fortsatta livslängd. (Jag gillar regressionstester). Notera dock att detta sätt att testa tar inte bort behovet av mer formella granskningar av systemets säkerhet, utan är ett komplement.

Arbetar du med utveckling och/eller drift av webbapplikationer och inte redan gör den här typen av tester kommer du troligen att hitta en del matnyttigt i den här artikeln.

Jag har precis lagt till en ny IT-säkerhetsblog till listan av bloggar. David LeBlanc är säkerhetsarkitekt på Microsoft. David har även varit med och skrivit ett antal av de böcker om säkerhet som Microsoft publicerat och David har tidigare arbetat med att jaga säkerhetsproblem både inom Microsoft och under sin tid utanför Microsoft.

Davids koppling till Microsoft, sin erfarenhet inom säkerhet och hans förmåga att uttrycka sig gör att iaf jag tycker att David LeBlancs blog är väl värd att läsa.

Jag har precis lagt till en länk till Joanna Rutkowskas blog invisiblethings. Joanna är en säkerhetsforskare som fokuserar på olika former av elak kod (malware).

Joanna blev känd förra året med sitt arbete med Blue Pill, en trojan som när den kommer in i ett system flyttar in hela systemet i en virtuell maskin. Därmed blir det oerhört svårt att från systemet detektera den elaka koden. Joanna har massor med andra intressanta idéer och tittar mycket på säkerheten i Windows, vilket gör hennes blog till en av de jag besöker regelbundet.

Jag skrev precis om RFC 4772. En annan intressant RFC som nyligen publicerats är RFC 4732 - Internet Denial-of-Service Considerations. RFC:ns sammanfattning lyder så här:

This document provides an overview of possible avenues for denial-
of-service (DoS) attack on Internet systems.  The aim is to encourage
protocol designers and network engineers towards designs that are
more robust.  We discuss partial solutions that reduce the
effectiveness of attacks, and how some solutions might inadvertently
open up alternative vulnerabilities.

RFC:n beskriver hur överbelastningsattacker fungerar, vad i protokoll, applikationer och system som gör dom möjliga eller förvärrar problemet, hur mer avancerade distribuerade attacker och förstärkningseffekter kan uppkomma på Internet. Utifrån dessa beskrivningar övergår sedan RFC:n till att beskriva vad man skall tänka på vid design, implementation och konfiguration av protokoll, funktioner och applikationer. Jag tycker att detta är en RFC väl värd at ge några minuter, oavsett om man arbetar aktivt, eller bara är nyfiken.

(Japp, jag är tillbaka efter en låång julledighet, så nu skall det bli lite bättre fart på Kryptoblog.)

I slutet av förra året publicerade IETF ett antal nya RFC:er där några berör IT-säkerhet. En av dessa är RFC 4772 - Security Implications of Using the Data Encryption Standard (DES). Men vänta nu, tänker du säkert, varör publicera en RFC om ett krypto som NIST drog tillbaka 2005. RFC:n förklarar detta så här:

The Data Encryption Standard (DES) is susceptible to brute-force
attacks, which are well within the reach of a modestly financed
adversary.  As a result, DES has been deprecated, and replaced by the
Advanced Encryption Standard (AES).  Nonetheless, many applications
continue to rely on DES for security, and designers and implementers
continue to support it in new applications.  While this is not always
inappropriate, it frequently is.  This note discusses DES security
implications in detail, so that designers and implementers have all
the information they need to make judicious decisions regarding its
use.

Den här RFC:n definierar alltså inte en ny standard, utan kommer med information och råd om säkerhetsläget för DES, hur DES attackeras och vad man bör tänka på. RFC:n ger följande råd:

o  If possible, use 3DES rather than DES (and in any case, DO NOT
make DES the default algorithm!).

o  Replace keys before exceeding 2^32 blocks per key (to avoid
various cryptanalytic attacks).

o  If there is a user interface, make users aware of the fact that
the cryptography in use is not strong, and for your particular
application, make appropriate recommendations in this regard.

Om du arbetar med att utveckla, underhålla eller på annat sätt är ansvarig för system där DES ingår tycker jag att du skall ta en titt på RFC 4772.