String pattern/algorithm for PIN & PUK generated from MSIN

Question

I wonder how mobile phone companies generate both PIN and PUK for their SIM cards?

I have a large database of already generated codes, this database contains 3 columns: * MSIN : Mobile Subscriber Identification Number (10 digits) * PIN : Personal Identification Number (4 digits) * PUK : Personal Unblocking Code (8 digits)

So far, maybe both PIN and PUK are generated from MSIN because the MSIN column is incrementing, while others, are generated with a logic, something like;

MSIN            PIN     PUK  
1000000000      3234    20005627  
1000000001      5993    92870018  
1000000002      3465    30327846  
...

is it possible to know how this serials are generated? Using the existing database is it possible to guess the algo used?

I'm asking this for the sake of knowledge only not to use the provided information in any illegal activity ;)

thanx.

UPDATE

I searched for how many times some pin codes are repeated and found this

0000 –> 261 times
1111 –> 429982 times
2222 –> 275
3333 –> 233
4444 –> 279
5555 –> 277
6666 –> 242
7777 –> 263
8888 –> 249
9999 –> 242

the pin 1111 is used more than others! so maybe the algo is changed from time to time.. or ther's no logic at all inside :(

UPDATE 2

I checked the MSIN and found that they make jumps in the incrementing system, so for example;

1011000000
1011000001
…              here they followed incrementing until 1011499999     
1011499999     and they jumped to 1031000000
1031000000
…              the same thing here
1031299999
1131000000
… 

this leads to an idea that whenever they want to issue new cards, lets say 500 000 cards, they start with a new MSIN that doesn't follow the incrementing rule in the database and the may change the algo behind the code generation (that's why we find in some cases they issued all the next cards with pin 1111)

Answer 1

If we make the assumption that PUK/PIN are generated from the MSIN, there's a virtually infinite number of ways they could be doing this. To take one (reasonable) example, they could be using an HMAC. Even assuming you knew what hash algorithm they're using, you'd still have to determine the secret key, and the search space for that is on the order of 2^160 (for HMAC-SHA1) - totally impractical to search exhaustively.

The only chance you have is if they're doing something stupid, like using an easily guessed or determined algorithm to generate the PIN/PUK - and there's no practical mechanical procedure to work that out, just trial, error, and intuition.

Answer 2

The answer can go from really easy to pretty complex.

If I had to design the system, the f function (Pin,Puk) = f(MSIN) wouldn't be easy to guess, and, moreover, not reversible (meaning if you know (pin,puk) you cannot guess MSIN).

Because the subject is around security and payment, you can probably expect a complex function.

Unless it is documented somewhere on the net (which I doubt) it is very unlikely you will find the function f.

Answer 3

Usually its not the mobile network operator who generates the PIN and PUK. The SIM card manufacturer does this unless ordered otherwise by the operator.

What makes you believing that one can calculate SIM and/or PUK from the MSIN? Neither the network operator nor the SIM manufacturer would have any advantage from this. I would assume that PIN and PUK are as random as economically feasible in order to implement the intended security.

However, I find the 1111 anomaly interesting. Is your sample right from manufacturing? Or did you get an HLR dump? The latter one might provide an explanation for the 1111 cumulation: People change their PIN to something easy to remember and to type, 1111 would be the most common candidate for this.