Advertisements

General Musing

blaze your trail

Posts Tagged ‘sms

A catalog of this year’s risky articles #2010

leave a comment »

Programming Hands

Risk is something which can be difficult to evaluate for the average person, there is a lot of work which goes in to learning not to do the two things that people usually do when they are confronted with risk:

  1. Ignore
  2. Overreact

It looks like every man and his dog needs to have a Facebook page, even banks…

It has been almost 1.5 weeks since Google’s FeedBurner removed the Frie…

Some days ago I tweeted to Prosper, a personal loan marketplace, whether they…

I don’t really think most people get “it” when it comes to …

Just noticed that Google Translate translates the name of the Dutch social ne…

I find a 400 plus page manual of office policies and job descriptions for eac…

In the last two days I’ve not been posting so much, and focussing on up…

I started playing with Google Scribe and wanted to see if patterns emerged so…

I have my Google account set up with English as the preferred language, my br…

For the last 2 years LinkedIn has been running a bad poor IT management depar…

When I just started I too had trouble with getting all the items I required t…

On August 11th 2007 I exceeded my GMail quota, I blogged about it here. At th…

Brian Szymanski send a reply to me concerning another bank implementing SMS b…

I don’t understand why url expansion after url shortening is such an is…

I just read an article Web Coupons Know Lots About You, and They Tell in the …

This morning/night China’s networks were sending rerouting messages to …

The lack of trained and experienced computer security people working in small…

Last week I saw an episode of a popular Dutch Ombudsman program Kassa, they r…

After seeing a program about a lifecoach trying to find the time to get his p…

Image source Radio Nederland Wereldomroep

Advertisements

More SMS banking by M&T #sms #bank #risk

with 2 comments

Brian Szymanski send a reply to me concerning another bank implementing SMS banking: M&T. Their demo, which you can find here, shows that currently you can only do balance inquiries, but it is a slippery road to implementing more features.

As I have stated numerous times before, SMS is not a secure method, even discounting the ability to snoop SMS. The sender number embedded in a sms is a 7-bit/11-byte length field containing a trailing F, specifications say this should be decimal semi-octets. What it doesn’t say, but is reasonably well known is that this is to all intents an alpha-numeric field which is set by the sender. This mean using this field you can spoof the sender, and using blind spoofing you may be able to fool the bank into performing a transaction. And if you are like many people you will not type the phone number when you reply you will reply to the message, so there is a possibility to blind spoof the user into performing a transaction or sending you transaction data. Which leaves the possibility of data leakage. Add that to the fact I can get the messages out of the air, and can either decrypt them or make rainbow tables[1]. There are so many attack vectors in SMS banking that I believe it’s not secure.

From GSM service security:

GSM uses several cryptographic algorithms for security. The A5/1 and A5/2 stream ciphers are used for ensuring over-the-air voice privacy. A5/1 was developed first and is a stronger algorithm used within Europe and the United States; A5/2 is weaker and used in other countries. Serious weaknesses have been found in both algorithms: it is possible to break A5/2 in real-time with a ciphertext-only attack, and in February 2008, Pico Computing, Inc revealed its ability and plans to commercialize FPGAs that allow A5/1 to be broken with a rainbow table attack. The system supports multiple algorithms so operators may replace that cipher with a stronger one.

If they stick to balance inquiries then it can be an acceptable risk, I even do balance inquiries using MSN with my bank, and this only slightly better security wise.

  1. Research May Hasten Death of Mobile Privacy Standard

Written by Daniël W. Crompton (webhat)

April 22, 2010 at 12:33 pm

Posted in business, finance, risk

Tagged with , , ,

Predictable Initialization Vectors #security #cryptography

with one comment

I’m always amazed that people use unixtime as a unique number for anything, even unixtime in milliseconds. A request that comes in milliseconds from the next might just pass muster, but for cryptography this is just not enough!

Sorry let me start from the beginning…

Due to some restrictions at regarding SSL certificates I was forced to come up with a way to encrypt sensitive data being passed from a user’s browser to an application server. I thought it would be pretty simple to build my own Diffie-Hellman key exchange in JavaScript, which it was. Encryption on the otherhand is not my forté, so I thought I would rely on somebody else for that work. It was suprisingly difficult to find a Cipher Block Chaining implementation of Rijndael (Advanced Encryption Standard, AES) in JavaScript, so I decided to go with the Counter Mode implementation I found over at AES Advanced Encryption Standard.

Al was well, the implementation was a little tricky as I was made some mistakes in my Diffie-Hellman implementation due to the lack of Big Number support in JavaScript. Once I’d finally solved that with a dive into arrays of numbers I was suddenly presented with strange behavior. All the encrypted blocks in a sequence seemed to start with the same block, 4 bytes which were similar in all messages and then 4 bytes which were identical. There was nothing wrong with the implementation. The SharedKey was always different – I was using an 64 bit key for testing – and I could decrypt the messages fine on both sides. I was a little baffled.

So when I was reading about the new SHA3 on Bruce Schneier‘s blog and thought that it could have something to do with the Salt, as SSHA or Salted SHA. The Salt is almost identical to the Initialization Vector or nonce used in Cryptography. So I examined the JavaScript code and saw this:

var counterBlock = new Array(blockSize);
var nonce = (new Date()).getTime(); // timestamp: milliseconds
var nonceSec = Math.floor(nonce/1000);
var nonceMs = nonce%1000;
for (var i=0; i<4; i++) counterBlock[i] = (nonceSec >>> i*8) & 0xff;
for (var i=0; i<4; i++) counterBlock[i+4] = nonceMs & 0xff;
var ctrTxt = '';
for (var i=0; i<8; i++) ctrTxt += String.fromCharCode(counterBlock[i]);

Needless to say I was surprised, also because initially I hadn’t even noticed that the last 4 bytes of the 8 byte sequence were identical. So I double checked the rest of the code and saw that indeed the IV was prepended to the encrypted block. Shocking was the fact that unixtime was being used to create the nonce. Unix time is the number seconds since the January 1st, 1970 in UTC, which means that the current time and date can be extracted. For each second that passes only one is added to the total, which means that the first portion is predictable as long as you know what date and time it is in UTC. The second part can be guessed or even pre-calculated in a rainbow table, there are after all only 86400 seconds in a day. What’s worse is that the number of milliseconds, is always less than 1000, so we can look it up in the same rainbow table we created for the seconds of the day. That means that this entire IV is predicable, as long as we can read a calendar and tell the time, or have a computer to do it for us.

So I took out my trusty editor and plugged the hole like this:

function generateIV() {
var counterBlock = new Array(16);
var nonce = Math.floor(Math.random()*18446744073709551616)
var nonceSec = Math.floor(nonce/4294967296);
var nonceMs = nonce%4294967296;
// encode nonce with seconds in 1st 4 bytes, and (repeated) ms part filling 2nd 4 bytes
for (var i=0; i<4; i++) counterBlock[i] = (nonceSec >>> i*8) & 0xff;
for (var i=0; i<4; i++) counterBlock[i+4] = (nonceMs >>> i*8) & 0xff;

var ctrTxt = ”;
for (var i=0; i<8; i++) ctrTxt += String.fromCharCode(counterBlock[i]);

return ctrTxt;
}

I then I used the scatter chart option in Open Flash Chart 2 to create a distribution chart to verify that the distribution of x = nonceSec and y = nonceMs was random, which as far as I could determine it was. Had the person who wrote this had done the same he would have seen how predictable his nonce was and could have fixed it.

So what did you do today?

UPDATE: I had a discussion with Chris Veness, the author of the library I referred to above, and he said the following:

There is no suggestion that the nonce needs to be unpredictable (though it must be unique), hence your concerns are, to the best of my understanding, entirely misplaced.

I feel much more comfortable following SP800-38A to the letter (as I believe I have done with the ‘second approach’), rather than second-guessing what might be improvements, as I have noticed that for a non-expert, alterations which intuitively appear to improve cryptographic strength can potentially have exactly the reverse effect.

Further, while your change results in a low likelihood of compromising uniqueness, it is clearly breaching this cardinal requirement of the specification (“A procedure should be established to *ensure* the uniqueness of the message nonces”).

I trust you will update your blog so that your readers won’t get drawn into a similar confusion.

Technorati technorati tags: , , , , , ,

Written by Daniël W. Crompton (webhat)

November 20, 2008 at 7:54 pm

USSD – A Mobile Payment Solution? #mobile

with one comment

Somebody send me a nice demo which Barcleys in India is implementing or has implemented using Unstructured Supplementary Service Data.

USSD is part of the GSM standard which tends more towards a real-time messaging service, unlike SMS no data is stored on the mobile or network. All the data still goes over the same channel over the GSM network, and thus is still inherently insecure, due to the fundamental flaws in the GSM encryption methodology.

One of the advantages over SMS is that nothing sits in between to store messages, so they must be answered immediately. The back end application is responsible for the message handling, as it is completely session oriented. There is both a push and pull method, which means communication is initiated from the mobile or network. IMHO this still leaves it susceptible to a man-in-the-middle attack.

Do banks consider this acceptable risk? Or do they just not know the whole truth?

Technorati technorati tags: , , , , , ,

Written by Daniël W. Crompton (webhat)

August 1, 2008 at 1:15 pm

Posted in mobile, network, risk, security

Tagged with , , , , , ,

Reserve Bank of India halts mobile payments #risk

with one comment

I mentioned the insecurity of mobile payment systems before in Rabobank has insecure SMS banking. Apparently the RBI has the same reservations I do. In the article RBI puts a temporary halt on Mobile Payment Services explains.

They haven’t stopped regular services such as requesting bank balance, but they have halted signing off on permitting projects to go life until the final guidelines have been issued, micropayments and larger transactions.

From the draft guidelines:

It is suggested that the banks issue a new mobile pin (mPIN). […] Banks and the various service providers involved in the m-banking should comply with the following security principles and practices with respect to mPIN : […]
Protect the mPIN using end to end encryption

They don’t seem to require One Time Passwords, which I would certainly have as a requirement, and I hope they don’t consider A5 to be end-to-end encryption. Nokia and Visa already started working on a secure payment system in 2007 using RFID.1

Technorati technorati tags: , , , ,

Written by Daniël W. Crompton (webhat)

July 26, 2008 at 5:53 pm

Rabobank has insecure SMS banking

with 4 comments

The Rabobank has a new service called Rabo SMS Betalen, the purse can be accessed by SMS.

  1. Alice sends a message to 6689 with the phone number and amount in the body, either +316-<number> or 06-<number>

    0612345678 15 Thanks for the money, Bob.

  2. Alice receives a confirmation SMS from 6689 with an OTP (One Time Password)
  3. Alice sends the OTP back by SMS to 6689 confirm the transaction
  4. Bob, the recipient, receives a confirmation SMS from 6689 that money has been transferred from Alice’s phone number

There are a number of issues with this, primarily that it is possible to perform a man-in-the-middle attack on this system with less than $1000 worth of equipment.

From GSM Security:

GSM uses several cryptographic algorithms for security. The A5/1 and A5/2 stream ciphers are used for ensuring over-the-air voice privacy. A5/1 was developed first and is a stronger algorithm used within Europe and the United States; A5/2 is weaker and used in other countries. Serious weaknesses have been found in both algorithms: it is possible to break A5/2 in real-time with a ciphertext-only attack, and in February 2008, Pico Computing, Inc revealed its ability and plans to commercialize FPGAs that allow A5/1 to be broken with a rainbow table attack. The system supports multiple algorithms so operators may replace that cipher with a stronger one.

I wonder who sold them this idea?
Technorati technorati tags: , , , , ,

Written by Daniël W. Crompton (webhat)

July 9, 2008 at 12:20 pm

Posted in finance, risk

Tagged with , , , , ,

%d bloggers like this: