Som några här kanske känner till så får inga nya betalkortslösningar sättas ut efter årsskiftet som inte stödjer EMV och PCI-DSS. PCI-DSS är ett mycket omfattande dokument som beskriver alla säkerhetsbrister i moderna operativsystem (såväl Windows som Linux), databaser och webgränssnitt. Många företag som försöker uppfylla PCI-DSS sliter säkert sitt hår pga all denna "användarvänlighet" och brist på säkerhetstänkande i moderna operativsystem, databaser och webapplikationer.

Fast det gör inte jag. Förra veckan fyllde jag i PCI-DSS för vår framtida betalkortsterminal, och det var hur enkelt som helst att uppfylla detta. Här är de primära orsakerna till detta (varav de flesta hänför sig till RDOS operativsystem):

1. Det finns inga användare eller remote-access -> ingen obehörig kan manipulera systemet

2. Det finns inget Windows- (eller Linux) GUI där man kan logga in -> användare kan inte manipulera eller ställa till

3. Kommandotolken kommer antagligen att plockas bort i "productions-releasen" -> ingen användare-access öht till filsystemet förutom den som finns i vår betalkortsapplikation

4. Det finns inga okända öppna portar -> man behöver inte skanna för säkerhetsriker

5. Det går inte att konfigurera drivrutiner i "run-time" -> ingen kan sätta på några säkerhetsrisker

6. Hela OSet finns i en enda fil som har CRC-checksummor per drivrutin -> ingen kan öht ändra på konfigureringen av någonting alls

7. Känsliga data sparas inte i databas eller på fil -> ingen kan komma åt känsliga data även om de skulle ha direkt access.

8. Alla ingångar stängs av i brandväggen -> ingen ifrån Internet kan etablera en förbindelse.

9. Betalapplikationen är skriven i C++ och kompilerad för 32-bitars RDOS
-> inga skript som kan ändras eller manipuleras

10. Betalapplikationen är inte beroende av tredjeparts DLL-filer, visual controls eller andra komponenter -> den kan inte manipuleras genom att ersätta filer, utan hela applikationen (förutom utseende på GUI och språktexter) finns i en enda kompilerad fil.

Kort sagt, hade det inte varit för värdelösa moderna operativsystem som Windows och Linux, så hade man inte behövt vara orolig för att kortdata skulle komma på avvägar.

Förresten så ska PBS testa vår terminal den 21/12, och då får vi förhoppningsvis oxå ett godkännande som gör att vi så småningom kan börja sätta ut EMV-terminaler nästa år. Såvitt jag förstår så blir vi först i Sverige med att ha en EMV-godkänd tankningsautomat.

rdos skrev:1. Det finns inga användare eller remote-access -> ingen obehörig kan manipulera systemet

2. Det finns inget Windows- (eller Linux) GUI där man kan logga in -> användare kan inte manipulera eller ställa till

Vilket också betyder att om man skulle vilja elelr till och med behöva uppdatera systemet så måste man åka ut till varje enskild terminal?

rdos skrev:5. Det går inte att konfigurera drivrutiner i "run-time" -> ingen kan sätta på några säkerhetsrisker

6. Hela OSet finns i en enda fil som har CRC-checksummor per drivrutin -> ingen kan öht ändra på konfigureringen av någonting alls

(Min fetmarkering)
Du anvönder alltså inte en kryptografisk signatur? Isåfall kan väl en attackerare med fysisk access och tillgång till binärerna manipulera dessa och skriva över det gamla CRC-värdet?
Finns det någon chain of trust eller kan en attackerare helt enkelt byta ut disken? (eller vilket medium som nu används)

Och så en annan tanke, orelaterat till säkerhet, iom användning av RDOS är man väl knuten till x86?

nitro2k01 skrev:Vilket också betyder att om man skulle vilja elelr till och med behöva uppdatera systemet så måste man åka ut till varje enskild terminal?

Nej, det finns en genial lösning på detta problem. Man ansluter inte själv till systemet för att uppgradera det, utan systemet ansluter till en fast FTP-address för att kolla uppgraderingar med jämna mellanrum.

nitro2k01 skrev:Du anvönder alltså inte en kryptografisk signatur? Isåfall kan väl en attackerare med fysisk access och tillgång till binärerna manipulera dessa och skriva över det gamla CRC-värdet?
Finns det någon chain of trust eller kan en attackerare helt enkelt byta ut disken? (eller vilket medium som nu används)

Nej, inget av detta finns. Man kan byta ut hela disken om man så vill, men det kräver nycklar till terminalen eller ett funktionskort. Dessutom så kräver det att man kan sätta i en ny disk som fungerar om man ska kunna sno känslig information typ kortstrippar. Vår applikation hanterar inte själva betalfunktionen själv, utan för det har vi en Linux-baserad lösning ifrån BBS i danmark. Deras system måste vi oxå skydda, vilket vi gör i brandväggen genom att inte tillåta access in till det. Deras disk är inte utbytbar, däremot så är PSAMen det.

Själva CRC-funktionen i RDOS är egentligen en bieffekt av ett tidig designval. Då var avsikten att RDOS skulle kunna placeras i ett ROM som man kunde boota direkt ifrån utan disk. Denna lösning finns oxå ute på GLC. Iaf så fungerar boot-loadern så att den först läser in hela binärfilen till minnet. Därefter så skannas minnet för giltiga signaturer & CRC-värden. Denna skanning hittar både PROMade drivrutiner och de som fanns i binärfilen.

nitro2k01 skrev:Och så en annan tanke, orelaterat till säkerhet, iom användning av RDOS är man väl knuten till x86?

Det är korrekt, men knappast något problem i dagsläget. Det som behöver lösas är APIC-funktionen (och gärna även stöd för flera kärnor) som gör att vissa nya moderkort inte fungerar med RDOS. Däremot så fungerar alla inbyggda PC vi testat.

rdos skrev:

nitro2k01 skrev:Vilket också betyder att om man skulle vilja elelr till och med behöva uppdatera systemet så måste man åka ut till varje enskild terminal?

Nej, det finns en genial lösning på detta problem. Man ansluter inte själv till systemet för att uppgradera det, utan systemet ansluter till en fast FTP-address för att kolla uppgraderingar med jämna mellanrum.

Fast om binären man inte skickar ut är krypterad och signerad går den enkelt att sniffa och/eller spoofa av en utomstående. Första steget till en attack torde vara att sniffa kommunikationen, vänta på en uppdatering och analysera hur protokollet samt binären är uppbyggd. Nästa steg blir följdaktligen att förgifta terminalen med en modifierad binär. (FTP är ju normalt helt okrypterat, men san kan du ju förstås mena något annat än just protokollet FTP, alt. ha lagt på något fluff för kryptering ovanpå protokollet.)
Om det är så att du inte använder kryptering för nerladdningarna så kanske du inte ser det som ett problem idag, bara för att du ansluter utåt. Men när det handlar om pengar kommer det alltid finnas någon som är reda att anstränga sig för att lura systemet, även om det tar flera år att baklängesingenjöra systemet osv. God säkerhet bör byggas offensivt och varje hål bör täppas igen.

rdos skrev:Det är korrekt, men knappast något problem i dagsläget. Det som behöver lösas är APIC-funktionen (och gärna även stöd för flera kärnor) som gör att vissa nya moderkort inte fungerar med RDOS. Däremot så fungerar alla inbyggda PC vi testat.

Nu var det dock inte x64 som jag ämnade jämföra med (som ju ändå är kompatibelt med x86 till stor grad) utan t ex ARM som verkar vara en populär arkitektur för embedded. (Om jag inte har missförstått saken så är stora delar av RDOS skrivet i asm) Men det var mest bara en lös tanke.

nitro2k01 skrev:Fast om binären man inte skickar ut är krypterad och signerad går den enkelt att sniffa och/eller spoofa av en utomstående. Första steget till en attack torde vara att sniffa kommunikationen, vänta på en uppdatering och analysera hur protokollet samt binären är uppbyggd.

Förvisso, men uppdateringar kommer nog bara att ske någon gång om året, eller ännu mer sällan. Däremot så kan sökningen efter uppdateringar vara mer frekvent. Fast en lösning på detta jag funderat på är att skicka kommandot "uppdatering" på den vanliga förbindelsen till vårt lokalkortssystem. Då måste man både knäcka detta protokoll (som är binärt och mellan fasta IP), och lura uppgraderingen att ansluta sig fel (vet inte om detta går, eller hur svårt det är). Vi kommer inte att använda DNS för FTP-förbindelsen, utan en fast IP address. Då måste man på något sätt lura Internet att skicka dessa IP-paket fel.

nitro2k01 skrev:Nästa steg blir följdaktligen att förgifta terminalen med en modifierad binär. (FTP är ju normalt helt okrypterat, men san kan du ju förstås mena något annat än just protokollet FTP, alt. ha lagt på något fluff för kryptering ovanpå protokollet.)

Nej, jag tror vi använder okrypterad FTP, möjligen med udda port och kanske även något udda meddelande, om det är genomförbart på serversidan.

nitro2k01 skrev:Om det är så att du inte använder kryptering för nerladdningarna så kanske du inte ser det som ett problem idag, bara för att du ansluter utåt. Men när det handlar om pengar kommer det alltid finnas någon som är reda att anstränga sig för att lura systemet, även om det tar flera år att baklängesingenjöra systemet osv. God säkerhet bör byggas offensivt och varje hål bör täppas igen.

Sant. Det tål att tänkas mer på...

nitro2k01 skrev:Nu var det dock inte x64 som jag ämnade jämföra med (som ju ändå är kompatibelt med x86 till stor grad) utan t ex ARM som verkar vara en populär arkitektur för embedded. (Om jag inte har missförstått saken så är stora delar av RDOS skrivet i asm) Men det var mest bara en lös tanke.

Det är korrekt. RDOS är skrivet i 100% asm, så det går inte att portera till t.ex. ARM. Men de flesta mer avancerade system använder fortfarande x86.
Däremot så har vi byggt in ett portabilitetslager i vår applikation så den kan flyttas till andra OS, och även andra plattformar. Något sådant lär dock enbart bli aktuellt om RDOS av någon anledning måste överges. Vi använder t.o.m. samma ramverk även för väldigt simpla, disklösa system baserade på V25-processorn. Det är dessa system som finns ute idag. För vårt mera moderna system har ramverket utvidgats en del med en portabel grafikmotor, TCP/IP och filsystemsanrop. Allt detta kan iaf teoritiskt flyttas till Linux. I dagsläget anser jag dock inte detta som meningsfullt eftersom RDOS har fördelar som överväger.

En måttligt genomtänkt fundering är om man skulle kunna använda kryptering med dubbla nycklar för uppdateringarna? Borde inte det vara närmast idiotsäkert?

Vi har nu fått vår EMV-terminal godkänd av PBS, dock med lite återstående punkter som ska vara fixade tills i slutet av januari. Vi får dock sätta ut fem stycken "piloter" om vi skulle vilja.