Den första observationen är publicerad på det öppna artikelarkivet Arxiv. Artikeln handlar om huruvida AES kan ses som en slumpmässig transform av indatat, eller om det finns ett detekterbart mönster – ett mönster som går att gissa. En ideal kryptoalgoritm skall möta den så kallade Random Oracle-modellen där det inte skall gå att på förhand gissa vilken sekvens som skapas. En avvikelse från denna slumpmässighet innebär en svaghet hos algoritmen.

Författarna tAnna Rimoldi, Massimiliano Sala och Enrico Bertolazzi skriver i sin artikel Do AES encryptions act randomly? följande:

With our attack we give some statistical evidence that the set of AES-$128 encryptions acts on the message space in a way significantly different than that of the set of random permutations acting on the same space.

While we feel that more computational experiments by independent third parties are needed in order to validate our statistical results, we show that the non-random behaviour is the same as we would predict using the property of our embedding.

Indeed, the embedding lowers the nonlinearity of the AES rounds and therefore the AES encryptions tend, on average, to keep low the rank of low-rank matrices constructed in the large space. Our attack needs 2**23 plaintext-ciphertext pairs and costs the equivalent of 2**48 encryptions.

We expect our attack to work also for AES-192 and AES-$56, as confirmed by preliminary experiments.

Om jag fattat det rätt kan författarna alltså särskilja/identifiera att en viss mängd data är krypterat med AES, eller om det är en rent slumpmässig sekvens. Dom kan alltså inte extrahera nyckeln. Och notera att dom behöver par med okrypterat och motsvarande krypterat material. Detta är mao inte en attack som gör AES värdelös, utan är snarare en observation.

Den andra artikeln, On Deviations of the AES S-box when Represented as Vector Valued Boolean Function, tittar mer specifikt på den substitutionstabell (S-box) som finns i AES.

S-boxen, även kallad SubBytes-steget i AES är en enkel tabell som byter ut en byte mot en annan. Tabellen ser ut så här:

S-boxen bidrar till kryptots olinjära egenskaper, men för att göra det skall det inte finnas något enkelt mönster bakom S-boxen, utan bör vara en slumpmässig hög med tal. Samtidigt vill man väldigt gärna veta varifrån dessa konstanter kommer ifrån – hur dom genererats.

Säkerhetsexperten Bruce Schneier brukar prata om Nothing up my sleeve numbers som en viktig egenskap hos en säkerhetsfunktion. Vad han avser med denna egenskap är att det inte skall finnas hemliga antaganden eller delar av funktionen, delar vilkas säkerhetsmässiga betydelse inte går att avgöra. Bra specifikationer talar därför om varifrån konstanter kommer ifrån.

I fallet med AES S-box är det i standarden är det tydligt specificerat att den genereras på ett specifikt sätt. Wikipedia ger en bra beskrivning av SubBytes:

In the SubBytes step, each byte in the array is updated using an 8-bit substitution box, the Rijndael S-box. This operation provides the non-linearity in the cipher. The S-box used is derived from the multiplicative inverse over GF(28), known to have good non-linearity properties. To avoid attacks based on simple algebraic properties, the S-box is constructed by combining the inverse function with an invertible affine transformation. The S-box is also chosen to avoid any fixed points (and so is a derangement), and also any opposite fixed points.

Att man känner till hur S-boxen är genererad utnyttjas även i vissa AES-implementationer som istället för att ha en fast tabell på 256 Bytes räknar ut S-boxen under det att transformen genomförs. Detta tar tid, men sparar minnesutrymme.

Nå, tillbaka till artikeln. Vad författarna Danilo Gligoroski och Marie Elisabeth Gaup Moe visar är att, till skillnad på vad Wikipedia säger visar sig S-boxen inte vara riktigt så slumpmässig och vara så icke-linjär som man skulle kunna hoppas utifrån ett idealperspektiv, och vad man tidigare antagit. Författarna skriver:

In this paper we give an explicit representation of the AES S-box as a vector valued Boolean function in GF(2)8 and show several significant deviations in the number of terms that follows from that representation when it is compared with the algebraic representation of randomly generated permutations of 256 elements. We see this as a potential research direction in cryptanalysis of AES.

Inte heller denna artikel visar på en direkt, praktisk attack – utan är en observation. En av författarna, Danilo Gligoroski har även sagt på en maillista att han inte ser speciellt stora möjligheter att utnyttja deras observation i en seriös attack.

Vad är då slutsatsen efter denna långa postning? Ungefär det här: AES har inte fallit, långt ifrån det. Men tillsammans med tidigare publicerade attacker de senaste åren visar de här artiklarna på att det sker framsteg inom kryptanalysen.

Detta visar även hur viktigt det är att låta utvärdering av algoritmer ta tid och att vid systemdesign inte binda sig stenhårt för en enda algoritm vid systemdesign. Det kan hända att den algoritm så såg bra och säker ut vid design, några år senare visar sig vara svag. Om systemet och det systemet hanterar har längre livslängd än så behöver man kunna byta ut algoritmerna, att vara flexibel.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Ericsson och Motorola har ingått en allians för att gemensamt ta fram LTE-lösningar för området ”allmän säkerhet”, det område som idag domineras av standarden Tetra och där Motorola är en av de starkaste aktörerna. Tanken är att kombinera Motorolas kompetens inom säkra nät med Ericssons förmågor inom LTE och mobilt bredband.

Ett mål med alliansen är att utveckla en LTE-lösning för mobilt bredband till säkerhetskritiska tillämpningar, som kan fungera tillsammans med säker röst- och datakommunikation. Enligt en gemensam pressrelease ska Motorolas nästa generations plattform för området innehålla LTE-teknik, klara behoven från såväl kommandocentraler, och kunna kommunicera med såväl tålig radioutrustning och terminaler i fordon som handhållna LTE-terminaler.

Som ETN påpekar meddelande även Samsung att dom skall samarbeta med säkerhetsjätten Thales om att utveckla TETRA-mobiler som stödjer LTE. I det fallet är det Thales som står för TETRA-kompetensen och Samsung för LTE-kompetensen (och att bygga mobiler får man anta).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Referenskoden är inte kanonsnygg och rätt dåligt dokumenterad. Bland annat stämmer inte namn med specifikationen, man gör egen definition av typer där man rimligen borde använd stdint.h och det finns inget körbart exempel. (I ärlighetens namn är det dock inte den sämsta referenskoden jag sett för ett krypto – kryptologer verkar i gemen vara rätt dåligt insatta i hur man skriver kod.)

Det var dock inga större problem att få snurr på ZUC och generera lite nyckelströmmar. På min laptop och med referenskoden får jag ca 250 Mbit/s när jag genererar block om 100 miljoner ord. Inte kanonhög prestanda, faktiskt något förvånande om man jämför med Snow.

Vad gäller algoritmen i sig och de naiva analyser jag kan göra ser jag egentligen inga nya saker. Jag hittar ingen bias mot några värden i Sboxarna, utan dom är rektangelfördelade. Initiering och klockning av interntillståndet ser väldigt mycket ut som i Snow. Däremot är det fortfarande oklart varför man valt de magiska konstanter och just de Sboxar man gjort. Vidare är det frågan hur mycket det påverkar att bara ha två Sboxar istället för fyra som i Snow.

En hårdvaruimplementation av ZUC ser ut att vara ungefär lika svår att göra som en implementation av Snow, dvs inte alls speciellt svårt och ge en kompakt implementation. Och då uppdatering av LFSR-kedjan samt uppslagning av Sboxar går att parallellisera borde det gå att få en rejäl prestandaökning jämfört med en SW-implementation.

Slutsatsen jag kan dra är att specifikationen verkar stämma med referenskoden och att det går att generera nyckelströmmar som stämmer med testvektorerna. Kan man lita på säkerheten hos ZUC ser det ut att vara ett helt ok strömkrypto. Det finns inga stora märkligheter men heller inget speciellt attraktivt och speciellt. Det är därför knappast av tekniska skäl som ETSI/SAGE, 3GPP och GSMA standardiserar ZUC. Speciellt då man precis standardiserat Snow 3G ger ZUC knappast någon algoritmisk diversitet, då borde man istället valt Trivium, Grain eller Rabbit, alla tre strömkrypton från eSTREAM-sviten med stora skillnader i struktur och uppbyggnad i jämförelse med ZUC och Snow..

Nej valet av ZUC handlar nog enbart om att möta kraven för access till en marknad och möjligheten att tjäna stora pengar. Förhoppningsvis blir vi som konsumenter inte lidande.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Kärnan i dessa algoritmer är ett nytt symmetriskt strömkrypto kallat ZUC. GSMA har även publicerat ett utkast till specifikation för ZUC samt en design- och utvärderingsrapport av ZUC, 128-EEA3 och 128-EIA3 skriven av ETSIs säkerhetsorganisation SAGE.

För att ZUC, 128-EEA3 och 128-EIA3 skall bli officiella standarder behöver 3GPP godkänna dom och GSMA vill därför få in kommentarer och undersökningsresultat på algoritmerna. (Nej, jag blir inte heller klok på relationen mellan GSMA, ETSI, SAGE och 3GPP.)

ZUC är ett krypto som har en 128-bitars nyckel och 128-bitars initieringsvektor (IV). Tittar man på strukturen hos ZUC rent översiktligt ser man relativt stora likheter med Svenska strömkryptot Snow 2.0 (i fortsättningen bara kallad Snow. Notera att det även finns en version av Snow utvecklad av ETSI/SAGE för 3G och LTE kallad Snow3G):

Strukturen hos ZUC.

Strukturen hos Snow 2.0.

Båda kryptona har en linjär del i form av ett skiftregister (LFSR eller LFSR-kedja). Samt en olinjär del (markerad med F i ZUC-figuren) implementerad i form av en tillståndsmaskin med en utbytestabell (Sbox). Båda krypton arbetar på ord om 32-bitar och det totala interntillståndet för ZUC är 560 bitar.

Ett par saker som skiljer ZUC från Snow är att där Snow har plockar ut ett par ord från LFSR-kedjan för att mata tillståndsmaskinen med har ZUC en filterfunktion som plockar bitar från fler ord i kejdan och kombinerar dessa till de ord som matar tillståndsmaskinen. Även återmatningen i LFSR-kedjan samt hur initieringen går till skiljer. En annan sak som skiljer är att de Sboxar som används i ZUC består av två tabeller om 256 element, medan Snow har fyra tabeller om 256 element.

Så långt gått och väl. Tittar man på konstruktionen och exempelvis ser på vilka operatorer som används och antalet register som behövs för att lagra interntillståndet ser ZUC ut att kunna vara ett kompakt krypto (både implementerat i SW såväl som i HW) med bra prestanda.

Problemet med ZUC är istället politiskt.

ZUC är nämligen specificerat av Data Assurance and Communication Security Research Center (DACAS), en del av Kinesiska vetenskapsakademin. Kina kräver nämligen att få specificera vilket krypto som skall användas i LTE, och LTE-Advanced-system som får säljas i Kina.

På den sida med forum som satts upp för ZUC pågår en ganska het debatt och även på olika krypto- och säkerhetsrelaterade maillistor pågår diskussion där många är väldigt tveksamma. Många ifrågasätter varför Kina får möjlighet att specificera ett krypto när inga andra länder gör det. Vidare ifrågasätts utvärderingen som utförts, inte minst för att ZUC inte utvecklats på ett öppet sätt så som det idag annars sker med internationellt accepterade algoritmer. Många påminner även om hur Kina försökte få in en egen säkerhetsstandard för trådlösa nät kallad WAPI (med det symmetriska blockkryptot SMS4).

En sak att lägga märke till är att ZUC, 128-EEA3 och 128-EIA3 inte är tänkt att enbart användas i Kina, utan är avsedda för internationell marknad, däremot är det de algoritmer så måste användas i Kina. Blir dessa algoritmer godkända kommer de att finnas med i kommande LTE-mobiler och basstationer.

Det jag inte gillar när jag läser specifikationen är att det inte finns någon förklaring till hur de magiska konstanter (D i specifikationen) har valts ut. För Sboxarna finns det i utvärderingsrapporten en kortare förklaring, men inte exakt varför man valde de värden man gjort.

Vidare är det frågan om man verkligen vågar lita på SAGE. De praktiskt genomförbara attacker som Adi Shamir m.fl utvecklat mot 3G-kryptot KASUMI har visat att de förändringar SAGE gjorde av kryptot MISTY1 för att utveckla KASUMU, förändringar avsedda att förstärka kryptot, är de som gjort kryptot så svagt. Dessutom är det tveksamt hur fristående SAGE är från de företag som avser att sälja LTE-utrustning till Kina. Att ETSI/SAGE accepterar en algoritm så är så snarlik Snow och Snow 3G när den senare nyligen godkänts visar att det inte handlar om säkerhetsmässiga skäl för de nya algoritmerna.

Jag är rätt övertygad om att ZUC, 128-EEA3 och 128-EIA3 kommer att bli 3GPP-godkända standarder. Det jag skulle vilja se innan dess är dock en större öppenhet vad gäller designval och en ordentlig omgång av öppna undersökningar, inte bara det SAGE och några inbjudna forskare genomfört på uppdrag av SAGE/ETSI, GSMA och Kina. Jag blir under alla förhållanden inte överraskad när SAGE konstaterar att:

Overall, taking into account all the feedback from the two paid evaluation teams, the SAGE task force concluded that the new algorithms are fit for purpose. The security margin appears to be high, and the design rationale clear. The SAGE task force has no objection to 128-EEA3 and 128-EIA3 being included in the standards.

En sista liten detalj. Undrar hur Inspektionen för Strategiska Produkter reagerar när man skall exportera ett kinesiskt krypto till Kina…

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Organisationen American Civil Liberties Union (ACLU) kritiserar i ett uttalande en skola i Kalifornien som försökt sätta RFID-taggar på alla elever i en skola. ACLU uppmanar föräldrar att vägra sätta på sina barn RFID-taggar som skolor delar ut.

Enligt en artikel i San José Mercury News är det en skola i Contra Costa County som vid terminstarten delat ut tröjor till alla elever. Tröjorna visade sig dock innehålla RFID-taggar. Det som skrämmer mig mest med denna nyhet är hur taggarna ses som en ren effektivitetslösning. Mercury News skriver:

RICHMOND, Calif.—California officials are outfitting preschoolers in Contra Costa County with tracking devices they say will save staff time and money.

The system was introduced Tuesday. When at the school, students will wear a jersey that has a small radio frequency tag. The tag will send signals to sensors that help track children’s whereabouts, attendance and even whether they’ve eaten or not.

School officials say it will free up teachers and administrators who previously had to note on paper files when a child was absent or had eaten.

Sung Kim of the county’s employment and human services department said the system could save thousands of hours of staff time and pay for itself within a year.

It cost $50,000 and was paid by a federal grant.

Mao, det viktiga är att spara pengar, och det verkar inte finnas några tankar om problem med tekniken. Undrar varför dom inte inför det på alla ställen i kommunen, exempelvis för skolpersonal och kommunens HR-avdelning…

Och när det väl uppdagas problem så blundar man istället. The Local rapporterar om en undersökning av de nya RFID-utrustade ID-korten i Tyskland.

Ett av de nya ID-korten i Tyskland som innehåller ett RFID-chip.

Dom nya ID-korten innehåller ett RFID-chip som bland annat lagrar fingeravtryck från två fingrar. Ett TV-program anlitade kända hacker-gruppen Chaos Communcation Club (CCC) för att testa säkerheten hos kortet. CCC lyckades extrahera information från korten. Men när de ansvariga ställdes inför faktum förnekade man att det ändå var möjligt:

In an interview with the show, Interior Minister Thomas de Maizière said he saw no immediate reason to act on the alleged security issue.

Meanwhile on Tuesday the Federal Office for Information Security (BSI) rejected the Plusminus’ criticism of the new ID card. The agency’s personal identification expert Jens Bender said the card was secure

Rätt skrämmande, inte minst för att det nya systemet är tänkt att användas för kommunikation med myndigheter, dvs det kommer att krävas ett RFID-utrustat kort för att komma åt tjänster som du som medborgare har behov av. Det blir därmed svårt att avstå från systemet. Det skall gå att istället använda en sexsiffrig PIN-kod, men frågan är hur länge det accepteras.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Adam Dunkels – pappa till uIP, bland annat.

Den nuvarande generatorn ger en monotont ökande sekvens som är lätt att prediktera. En ny generator skall ge en bra slumpmässig som inte är lätt (inte går) att prediktera. MEn samtidigt får storleken på stacken inte växa speciellt mycket och skall gå att implementera på en 8-bitars processor. Vidare får vi inte inför en massa nya krav på målsystemet, exempelvis tillgång till bra fysisk entropi. En icke-trivial kombination av krav.

Jag har tänkt, kladdat och sedan postat på Cryptography-listan och fått en del tips. Men jag (vi) tar med stor glädje emot mer klokskap. Här kommer därför min postning till listan. Läs, kommentera. Tack!

uIP [1] is a very compact TCP/IP stack for small, networked connected, embedded devices. (The code size for uIP including TCP and ICMP on the AVR processor is about 5 kBytes.)

Unfortunately, the TCP sequence number generator in uIP is a bit simplistic – basically a monotonically increasing number. In order to reduce the opportunities for TCP Spoofing (like this nice one [2]) we are trying to implement a new TCP sequence number generator.

What we want to find is an algorithm that generates a good (secure) TCP seq numbers, but use very little resources (on 8-bit computing devices).

We have done some preliminary investigations, have some rough ideas and would really appreciate comments and suggestions from the enlightened minds on this list.

As we see it, the two main problems to solve are:
(1) Find a secure PRNG algorithm that have as low implementation complexity as possible.

(2) Add as little system/application requirements on entropy source and persistent storage as possible.

Looking at TinyRNG [3] for example, it seems that a block cipher in CTR mode (or OFB mode) should be sufficient. The question then is what block cipher to use? The XTEA block cipher [4] is very compact, but would it be a wise choice from a security perspective?

But what to feed the PRNG with? Looking again at TinyRNG, it uses a simplistic version of the entropy accumulator from the Fortuna PRNG [5], but with fewer and smaller pools. The pools are processed using a CBC-MAC built around the same block cipher as used in the PRNG.

The combined storage for the pools as well as CBC-MAC state would probably be acceptable for uIP. The question is if the pool feeding operation as such adds operational requirements on uIP that makes it harder to integrate?

A simpler scheme could be to feed the PRNG (CTR-mode) with entropy used as part of Key and IV, that is not use a pool mechanism at all and leave it to user application to provide entropy words when performing a reseed. The Key (and IV?) would also consists of a counter that is monotonically increased.

The problem with this (we guess) is that in order to ensure that KEY+IV is never reused is to keep at least part of KEY or IV as a counter that is stored in persistent memory and increased once (and stored) every time reseed (or boot) is performed. (How bad from a security perspective would this be? Compared to other TCP sequence generators?)

The current version of uIP places few (basically no) demands on the system/application regarding physical resources (besides mem for code and data) and does not use any persistent storage besides code memory. It seems that any good sequence generator that are driven by physical entropy and tries to avoid sequence repetition need to place additional demands on the system. No?

This is basically as far as we have taken this. More or less a bit of Googling, reading and attempts at thinking. The ambition is not to invent something new and unproven but to adapt existing tech and ideas that seem to work. But get it to work with the size, performance and API constraints of uIP.

Any thoughts, comments, suggestions and pointers would be very greatly appreciated.

Thank you!
Joachim Strömbergson

References
—————

[1] A. Dunkels. uIP TCP/IP stack.

http://www.sics.se/~adam/uip/index.php/Main_Page

[1] R. Lawshae. Picking Electronic Locks Using TCP Sequence Prediction
http://www.defcon.org/images/defcon-17/dc-17-presentation/Ricky_Lawshae/defcon-17-ricky_lawshae-picking_electronic_locks-wp.pdf

[3] A. Francillon, C. Castelluccia. TinyRNG: A Cryptographic Random

Number Generator for Wireless Sensors Network Nodes

http://planete.inrialpes.fr/~ccastel/PAPERS/TinyRNG.pdf

[4] R. M. Needham, D. J. Wheeler. Tea extensions.

http://www.cix.co.uk/~klockstone/xtea.pdf

[5] Wikipedia. Fortuna PRNG.

http://en.wikipedia.org/wiki/Fortuna_%28PRNG%29

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Det finns flera källor för information om nyckellängder. Den som ofta förekommer är den i idag något gamla boken Applied Cryptography av Bruce Schneier som i kapitel sju har ett längre resonemang om olika nycklar och längder.

Vidare har NIST publicerat rekommendationer om nyckellängder, deras rekommendationer är dock från 2007. Även IETF har publicerat en RFC, RFC 3766 - Determining Strengths For Public Keys Used For Exchanging Symmetric Keys som innehåller ett längre resonemang om nycklars styrka, hur nyckellängder behöver skala med tiden, samt rekommendationer för assymetriska nycklar.

Det många av dessa källor tyvärr har gemensamt är att dom inte uppdateras speciellt ofta (alls). Webb-baserade källor borde därför vara av intresse att titta närmare på.

WIkipedia har förvirrande nog (minst) två sidor i ämnet, dels en sida om nyckellängder och en sida om kryptonycklar, båda med text om nycklar och längder. Borde nog slås samman och städas upp för att det skall bli användbart.

När jag letat runt efter olika referenser hittade jag att belgiska konsultfirman BlueKrypt har en fin sida som sammanställer rekommendationer om nyckellängder.

Den i mitt tycke bästa källan är dock en rapport. ECRYPT Yearly Report on Algorithms and Key Lengths, utgiven av det EU-finansierade ECRYPT II-projektet.

Som namnet antyder är det här en rapport som uppdateras en gång om året. Den senaste versionen kom ut sommaren 2009. Rapporten innehåller ett ordentligt resonemang om hur nycklars styrkor bör värderas (inklusive diskussioner om metoder som NIST, IETF och andra använder). Resonemanget leder så småningom fram till ett antal rekommendationer.

En viktig sak man gör i ECRYPT II-dokumentet är att sätta in styrkan i nycklar i hur kostsamt (rent ekonomiskt) det är att attackera en viss längd:

Jämför dom sedan olika typer av nycklar – symmetriska, assymetriska baserade på RSA, logaritmer eller ellitic curves får kommer dom med följande rekommendationer:

Slutligen sätter dom in längderna i ett tidsperspektiv – hur lång tid kan man anta att en nyckel med en viss längd ger ett skydd:

Vill du skydda något i 10 år från idag bör du alltså välja minst 96 bitars symmetrisk nyckel eller en RSA-nyckel på drygt 2400 bitar.

Allt detta förutsätter dock att algoritmerna som används inte har några svagheter. Den andra delen av ECRYPTS rapport innehåller en genomgång av de vanligaste algoritmerna inom olika kategorier – krypton, hashfunktioner, signaturer etc (DES, 3DES, AES, RSA, MD5, SHA etc). För varje kategori och specifik algoritm presenterar ECRYPT aktuell status vad gäller säkerhet och kommer med rekommendationer om vad man bör och inte bör använda. Mycket bra läsning.

En sista sak: exportreglerna för krypto i Sverige säger maximalt 56 bitar symmetrisk kryptering och maximalt 512 bitars assymetrisk kryptering (antagligen RSA) eller 112 bitar (antagligen elliptic curve).

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Förutom att ladda via USB kunde produkten köra en liten applikationen på datorn som visade laddstatus fäör batterierna.

Men det var nu inte det enda som kördes när laddaren kopplades in. Enligt Symantec kom batteriladdaren med en elak liten trojan. Symantec har en längre beskrivning av Energizertrojanen som bla beskriver vad den kunde göra:

• Download a file
• Execute a file
• Send a directory listing to the remote attacker
• Send files to the remote attacker
• Modify the following registry entry:

Energizer har dragit tillbaka produkten. Det jag undrar över är hur trojanen hittade in i koden till laddaren från första början. Hade det varit ett USB-minne hade det varit en sak, men nu är det inte det och då brukar mängden minne som finns vara högst begränsat. Märkligt.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Den stora mobilkonferensen GSMA World Congress 2010 börjar nästa vecka och tydligen har företaget Whatamap utvecklat den officiella konferensapplikationen. Miko fick ett meddelande till sin mobil om detta från ett för honom okänt nummer:

Ok, någon vill att han skall köra en applikation. Hur vet man då att det verkligen är den officiella appen och kod man kan våga ladda ner och köra? Jo för att dom säger att det är ok:

Notera texten You can trust this application: it’s the official MWC 2010 mobile guide. Jamendåså, då måste det vara ok. När Mikko försökte köra koden fick han naturligvis följande varning:

Allvarligt talat. Även om det ibland kan vara si och så med hur signering sker, men det är väl ändå bättre än den här typen av trams.

Skall mobilsystemen bli en plattform för säkra transaktioner, ersätta plånböcker och e-handel är det dags att bli seriös vad gäller säkerhet. Och då böja städa i sitt eget bo.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.