String pattern/algorithm for PIN & PUK generated from MSIN
-
29-09-2019 - |
Pergunta
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)
Solução
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
.
Outras dicas
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.
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.