South Korea Faces The Bill For Lock-in To Wintel

Sometimes in an accident things happen in slow motion and all the mistakes it took to get to where there is no escape“the Korean government made Redmond’s software a requirement for online shopping and banking; a historically weak spot in online security.” pile up in great clarity. That’s happening in Korea where the government made a long chain of mistakes in setting up an ID-system for citizens.

The biggy is that they required the use of M$’s OS to do all kinds of on-line and financial transactions. Now most of the citizens’ unique identification numbers are the property of criminals who stole them from various businesses. This was an election issue a couple of years ago and now the mess has hit the fan. It might be instructive for Koreans to read Exhibit 465 in US DOJ v M$: “We have won platform battles before. To_make history happen again, we must make the industry embrace Internet Explorer and ActiveX:
* establish a significant installed base of users (browser share is starting point),
*sell the benefits of our platforms to the content developers,
* convince the influential webmasters to switch to our standards and promote them,
* reach the producers,
* help the traditional developers (ISVs and corporate developers) write to the ActiveX platform, so they develop the
rich base of Web applications and controls that establishes the value of the platform,
* “activate” our partners to create a supportive environment of partners – able to sell, integrate and support our solutions and 3rd party ActiveX technology.”

Yep. M$ set the trap and Korea and many others fell for it. M$’s salesmen weren’t the least bit interested in Korea’s security. Korea just got over migrating from XP to “7”. They largely skipped “8”. Now would be a good time to have a security fiasco with “7”. Everyone clearly sees that other OS as insecure. China banned it in government. It would be sweet if Korea did the same. I can see legislators considering this legislation while the phone calls and e-mails pile up.

I expect Korea will have to redo everything and get it right this time. Let’s hope they demand GNU/Linux be used for on-line/financial transactions and to protect data but failing that let’s hope they make GNU/Linux optional and the people can decide. There’s something refreshing about a whole country aroused about insecurity with that other OS on the check-list of things to fix.

See South Korea faces $1bn bill after hackers raid national ID database.

See also Presidential candidate promises to kill crypto standard locking nation into IE

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , , , , . Bookmark the permalink.

30 Responses to South Korea Faces The Bill For Lock-in To Wintel

  1. DrLoser says:

    DrLoser, apparently marginally illiterate, wrote, “Do you have a cite for this interesting observation?”

    Illiterate? I do not think that word means what you think it means. Webster’s, 1913:

    Il*lit”er*ate (?), a. [L. illiteratus: pref. il- not + literatus learned. See In- not, and Literal.] Ignorant of letters or books; unlettered; uninstructed; uneducated; as, an illiterate man, or people. Syn. — Ignorant; untaught; unlearned; unlettered; unscholary.

    Any half-decent teacher should be able to spot a “marginally illiterate” student. Perhaps you weren’t even a half-decent teacher, Robert? Ah, logical banter at its most amusing!

    In passing, I note that skipping a sentence or two in a cite does not make one illiterate. (I didn’t do such a thing.) May I suggest that introducing the notion of password theft at the last moment, when no such notion is actually present in one’s cites, makes one at the very least an extremely questionable authority, Robert? I further submit that in this instance you are a completely biased and determinedly misleading one.

    Read the fucking article yourself.

    On the other hand, if criminals continue to exploit the stolen ID numbers for identity theft, that bill could look cheap in comparison.

    Does that sound like password theft to you, Robert? Does it? Does it? How?

    Does it sound like what I have been assuming all along, ie identity theft based upon the almost total lack of entropy in a South Korean SSID? Does it? Does it?

    Oh wait. It sure does.

    You need to brush up on your ability to parse the evidence.

    And when you are civil enough to brush up on your use of the word illiterate and to apologise, then I will be civil enough to retract my characterisation of your teaching abilities.

  2. DrLoser, apparently marginally illiterate, wrote, “Do you have a cite for this interesting observation?”

    RTFA! “South Korean President Park Geun-hye was one of 20 million people who took a hit when online fraudsters subverted three of her country’s credit card companies. She called for a rethink of the current ID system in response, leading to the hearings.”

    Even if intruders have the IDs some other way, how do you think they got the passwords, and there is lots of reference to ActiveX, you know, M$’s contribution to IT?

  3. DrLoser says:

    Incidentally, Robert, if you have proof that Microsoft systems allowed South Korean passwords to be stolen in bulk (it may well be so), then
    1) Why did you just now go off on an anecdotal journey about your own issues with Microsoft, which as I recall had nothing whatsoever to do with passwords?
    2) Why did you not mention this fairly pertinent accusation in your OP?
    3) Do you have a cite for this interesting observation? Warning: try to make it relevant to the South Korean issue. Otherwise, I am afraid, you are still assigning “biggie blame” where no “biggie blame” exists.

  4. DrLoser says:

    Sure it is. The IDs are a problem but M$ has allowed the PASSWORDS to be stolen in bulk. That is a biggie.

    Not at all the sort of thing you’d see in a Linux security vulnerability, is it?

    Never mind, let’s leave that alone. Pop quiz, Robert. What is the difference, in security terms, between

    a) A login name
    b) A password
    c) Authentication via a South Korean SSID?

    You may, or may not, choose to use the word “entropy” in your answer.

  5. DrLoser wrote, “that is not the biggie at all, is it?”

    Sure it is. The IDs are a problem but M$ has allowed the PASSWORDS to be stolen in bulk. That is a biggie.

  6. DrLoser says:

    Not my imagination. Not my reality either because by then I was running GNU/Linux.

    In this instance, yes, Robert, the “biggie” is a complete figment of your imagination.

    I’m going to accept all the rest of your latest post as Gospel Truth for the sake of argument. Here, I’ll do you one better:

    Every single Microsoft implementation of anything whatsoever, other than the South Korean SSID-based systems, has been a hopeless and costly and immoral and legally indefensible disaster.

    There. That’s a proposition that should make your eyes water. And for the sake of this discussion, I will accept it.

    Got nothing to do with the case in question, however, has it? The case in question deals specifically with the security of systems built on top of the South Korean SSID system.

    There is no evidence that Microsoft is specifically to blame for any of the consequent shambles.

    I have presented a comprehensive, though informal, proof that the real issue is the almost total lack of entropy in the South Korean SSID itself.

    So, in this particular case, Robert, I would argue and I would fully expect almost everybody to agree with me that you are being misled by your personal biases when you say:

    The biggy is that they required the use of M$’s OS to do all kinds of on-line and financial transactions.

    Because that is not the biggie at all, is it?

  7. DrLoser wrote, “your biggie is a complete figment of your own imagination.”

    Not my imagination. Not my reality either because by then I was running GNU/Linux. See Worm, e.g. I Love You:“The ILOVEYOU worm, also known as Love Letter, or VBS, or Love Bug worm, is a computer worm purportedly created by a Filipino computer science student. Written in VBScript, it infected millions of Windows computers worldwide within a few hours of its release. It is considered to be one of the most damaging worms ever.” Were you napping and missed that one?

    My favourite was M$ considering images to be executable. The bad guys just loaded up all kinds of images on the web and users were owned.

  8. oiaohm says:

    DrLoser reason for no cite is if you had read the effected products on the Heartbleed data it was listed. Sorry its a case you quoted stuff without doing the full reading required. If you had compared the damaged that particular bug was causing you should have knowing about the end of life Cisco VPN product that many governments are still using.

    Discontuined Cisco vpn product in Australia is integrated with of all things with the windows only software required to submit to tax office. Yes those programs directly start the old Cisco vpn and will not accept substitute note the new Cisco vpn does not provide the same control interface. So now its vpn inside vpn connection. Of course this only prevents outside attackers have a go at it. This is a layers of abstraction problem that is just growing and growing. Heartbleed is causing Australia software acquirement policies to be changed so items like VPN have to be done inside applications as wrappers so they can be replaced.

    Please know your topic before raising them Heartbleed is fair worse for people using closed source solutions on Windows that have happened to depend on openssl. Linux , OS X and BSD and so on have used a common shared openssl library so making the issue repairable. Closed source products and even open source products on windows have uses a per application runtime solution. Yes runtime containing openssl that some of them are end of life with no update possibility.

    DrLoser I called you a moron because that is exactly what you are being running with media reports without reading how big the real bug is. Closed source uses a lot of non restrictive license parts. Yes the closed source end of life cisco vpn product that uses openssl for Linux is secure since it used system provided openssl.

    The price of forwards compatibility support that requires a non unified runtime. Heartbleed is a good example to see the price.

    ShellShock is platforms running bash only. This mostly does not include Windows but does include OS X. OS X default shell is bash. But at least with bash under OS X user can choose to replace the part themselves so fixing the problem. OS X has been slower to patch their bash than all Linux Distributions.

    Heartbleed and ShellShock are damming for FOSS and Closed source solutions Dependant on FOSS alike. Problem is more damming on Closed source solution providers. So exactly DrLoser why are you holding these two examples up. They are in fact both examples why parties should go FOSS since those parts may be in your solution without or without using a full FOSS solution. Difference is the FOSS solutions will have the fixes sooner.

    Linux Foundation has started a proper funded project to Audit FOSS projects this has been long over due. USA Mil has helped out with coverity for Open Source applications but it has been a case that Open Source applications got to open in or opt out and has only been automated tools not a properly human team checking the operational logic.

  9. DrLoser says:

    Whoops, mis-edited.

    Apparently I have two instances of something or other.

    My point is, Robert, that you don’t even have a single one, do you?

  10. DrLoser says:

    The biggy is that they required the use of M$’s OS to do all kinds of on-line and financial transactions.

    Not to put words on keyboards, Robert, but “So, DrLoser can name two instances of serious vulnerabilities in FLOSS …”

    And I have spent considerable effort and time demonstrating beyond reasonable doubt and without any opposition whatsoever that your biggie is a complete figment of your own imagination.

    Do we really need to go back into calculation of entropy again?

    Just admit it. This is a hasty and misguided and completely incorrect OP, Robert.

    There. Feel better? Catharsis is good for the soul.

  11. DrLoser says:

    DrLoser walking moron.

    A perfect example of why I need to apologise to ram, who accused us trolls of resorting to personal abuse.

    I claimed that, in this week past, ram would see far more personal abuse from regulars than he would from trolls. I was wrong. I apologise for being wrong.

    What I should have said is that we’d see far more personal abuse from oiaohm. Even Dougie has been extremely well-behaved this week.

    ram was correct. Ignoring oiaohm and Dougie, which is something I recommend to everybody, the general tenor of this site over the last week has been remarkably inoffensive.

    Let’s see if we can keep this up, chaps!

  12. DrLoser says:

    So, DrLoser can name two instances of serious vulnerabilities in FLOSS but wishes us to ignore the thousands that have ravaged the world of IT for decades with non-FREE software.

    Actually I just challenged oiaohm on the factual correctness of his comparison. I based this on the following:

    1) He provided no cite (he still hasn’t).
    2) Nevertheless, I spent a good thirty minutes or so on Mitre and other sites trying to locate an exploit that matched his claim.
    3) I couldn’t, so I offered one of the more visible Cisco issues as a basis for discussion.
    4) I can’t find a single “exploit” for Cisco equipment that doesn’t require remote authentication.

    Well, since you’ve reminded me, I can. Heartbleed and Shellshock, as it happens. And other SSL vulnerabilities, I presume.

    Now, in what way does this imply that a commercial company with closed software, who happen to be relying on FLOSS in these cases, is a worse bet, security wise, than a commercial company that uses no FLOSS whatsoever?

    “Every other fool on the planet is doing it” isn’t really much of a justification for this proposition, is it?

    …but wishes us to ignore the thousands that have ravaged the world of IT for decades …

    This bee that you have in your bonnet about “putting words on other peoples’ keyboards,” Robert. Does it apply in both directions? Because I never said or even implied any such thing.

    As a matter of fact, in this case I welcome full documentation of this “ravaging,” including relevant cites, cost of exploit, and so on.

    Heartbleed was an information leak, very serious, but not an “exploit” in terms of taking control of systems directly. The information could contain passwords etc. to allow that.

    You might want to reconsider that. Yes, indeed, the information leak might have “contained passwords etc. to allow that.”

    That, in this case, being unauthorized control of one or more sub-systems, or indeed the whole system.

    Oh, and here’s a thought. If I can grab the credit card details of, say, 10,000 people, complete with any security details necessary (might even just be the PIN for ATMs), you know what? I could care less about gaining root access to some piddly little Linux machine. I’ve already hacked into the Big Time.

    It was fixed the same day it was released…

    No it wasn’t, Robert. To start off with, Heartbleed qua security exploit was “released” considerably in advance of when it was officially detected. Following on from that, it took a couple of days at least (I’m looking at SJVN’s analysis here) before properly validated fixes were ready. Following on from that, Linux doesn’t have an automated process to enforce this (Patch Tuesday is naughty in the sight of God), so who knows how long it took to patch all vulnerable systems? Or even (to be frank) whether all vulnerable systems are patched even now?

    And following on from that, closely related bugs were still being reported on 6th June — two full months after the initial brouhaha.

    And to repeat: I was making a narrow argument about the comparison between Heartbleed and ShellShock and the South Korean SSID fiasco.

    I didn’t drag the wider world of general Linux security incompetence into this discussion, Robert. You did.

    So, don’t give me any more of that “fixed on the same day” nonsense, Robert.

  13. oiaohm says:

    DrLoser walking moron. Cisco old discontinued never to be updated VPN product uses Openssl. So every Openssl bug with zero fix if your platform is Windows.

    Basically this is Heartbleed in closed source. The same bug same source library. Different response.

  14. DrLoser wrote, “Heartbleed and Shellsock require no sort of authentication whatsoever”.

    Shellshock requires an implementation that is just stupid. Even I, the incompetent, know not to use the system shell to interpret CGI scripts. The DHCP attack requires physical access to the LAN, which is some form of authentication.

    Heartbleed was an information leak, very serious, but not an “exploit” in terms of taking control of systems directly. The information could contain passwords etc. to allow that. It was fixed the same day it was released… I’ve had vulnerabilities in that other OS I could not fix for days.

    So, DrLoser can name two instances of serious vulnerabilities in FLOSS but wishes us to ignore the thousands that have ravaged the world of IT for decades with non-FREE software. Greed inspires producers of that other OS to deal with vulnerabilities as slowly as possible to maximize profit/minimize damage to the “brand”. FLOSS is about good software.

  15. DrLoser says:

    Cisco won SSL VPN contract in Australia. It is still in use even that its end of life and has a known exploit because its claimed it too costly to replace.

    Somewhat off-topic, oiaohm, although we’re at least talking about a specific security vulnerability in closed source software.

    The trouble is, you didn’t specify which one. CVE-2013-6686? I offer this as a sample: it’s a DoS. I can’t find a single “exploit”-type vulnerability in Mitre that doesn’t first require remote authentication.

    Whereas Heartbleed and Shellsock require no sort of authentication whatsoever. Which suggests that your equivalence is completely bogus.

    Incidentally, blaming a commercial company when the product in question is past EOL is just the teeniest bit fatuous, don’t you think?

  16. DrLoser says:

    The South Korea system is also showing the same problem. There is no updated document how applications for South Korea had todo things. South Korea like Australia left it up to vendors todo the right thing.

    As usual, you have absolutely no evidence for this assertion, do you, oiaohm?

    However, I take it that this means you now agree with me and disagree with Robert.

    The South Korean SSID issue has nothing whatsoever to do with choosing Microsoft as a vendor.

  17. oiaohm says:

    Deaf Spy
    You can’t possibly mean Hearthbleed and ShellShock, can you?
    The faults were worse than this. Using a encryption library that was encoding in rot13 was one of the faults found in the Australian audit. Those two recent FOSS faults compared what was found in Australian Governement authorization look angelic.

    There were cases of no encryption at all. Telnet is fine right as long as you hide it behind an application front end. AUSKEY was done properly. There are closed source and open source implementations of AUSKEY. AUSKEY has a document listing everything an implementation should do. That does get updated.

    The South Korea system is also showing the same problem. There is no updated document how applications for South Korea had todo things. South Korea like Australia left it up to vendors todo the right thing.

    OpenSSL and Bash both cases it was leave it up to the Vendor todo the right thing. But the faults in both are way more minor than the South Korea or the prior Australian authorization system.

    Cisco won SSL VPN contract in Australia. It is still in use even that its end of life and has a known exploit because its claimed it too costly to replace. So how does Hartbleed issues for 4 years sound to your Deaf Spy. Yes Cisco SSL VPN has had a Hartbleed equal issue and it still deployed by many governments around the world. Linux ssl solutions might be fixed. When you compare closed source SSL with open source SSL solutions. OpenSSL might not be the best but at least updates has been cost effective and being released. Not just stuff it.

  18. DrLoser says:

    DrLoser the big thing you have missed is the pathetic system South Korea is lack of peer review of security solution.

    Who says I’ve missed it, oiaohm? At least you’re on-topic, which is a very good thing to see.

    Now, about that “peer review of security solution” thing. This is an interesting area for discussion, and I’m glad you brought it up. Let’s leave the “peer” bit out for now and just consider the “review” part.

    The reason this is interesting is that it cuts to the heart of the FOSS argument, as demonstrated by your distinctly suspect conclusion in the rest of your post (partly refused by DeafSpy). What, exactly, is being reviewed?

    If you’re a Four Freedoms advocate, the answer is code, code, code and possibly more code. But that’s just completely irrelevant in this case.

    One the one hand you review the requirements and the proposed mechanisms. On the other hand, you test the proposed solution. This is true whether the implementation is FOSS or “commercial” (for some value of “commercial”).

    A review of the requirements here would surely have indicated that a twelve-digit ID with a single digit checksum was, in itself, a dicey proposition. It might be OK as part of a two-stage authentication process, but on its own it’s rubbish.

    One would then proceed to review the mechanisms. Now, neither of us know what those are. Maybe HTTPS is mandated, maybe not. Maybe any database storing this information is secure, maybe not. But all of that needs to be reviewed. Peer or not. Closed-source or open-source.

    And finally we come to testing the proposed solution. You could waste an awful lot of time in code review. Have you ever done a code review in your life, oiaohm? I would suspect not. Code reviews almost always catch syntactic errors rather than semantic or security errors. But they might work … a little.

    The main thing a reviewer does is pretty much what I just did, below. How is this thirteen digit number constructed? If I had to crack it, how much effort would it take?

    Clearly, in this case, almost no effort at all.

    I repeat:

    Even Gnu/Linux cannot beat entropy.

  19. Deaf Spy says:

    Closed source developer will take the lazy way when they think no one will ever find out. Problem here attackers will find out.

    You can’t possibly mean Hearthbleed and ShellShock, can you?

  20. oiaohm says:

    DrLoser the big thing you have missed is the pathetic system South Korea is lack of peer review of security solution.

    Lot of issues turned up in Australia when auskey was implemented because the prior implementations were closed and never reviewed so old historic methods had been used way past their expiry date.

    Closed source developer will take the lazy way when they think no one will ever find out. Problem here attackers will find out.

  21. DrLoser says:

    (For baseball fans, that’s “pitching 0 and 2.” Just thought I’d correct something I’m not allowed to edit. I stand by the rest.)

  22. DrLoser says:

    Clearly I am going to have to reinforce this point. To quote Robert at the OP:

    Sometimes in an accident things happen in slow motion and all the mistakes it took to get to where there is no escape.

    Incontrovertible This particular problem started rolling in 1968. No M$ involvement at all.

    That’s happening in Korea where the government made a long chain of mistakes in setting up an ID-system for citizens.

    Incontrovertible. The original 1968 algorithm is clearly unsuitable for any sort of secure transaction whatsoever. Robert is pitching 2 and 0 here!

    The biggy is that they required the use of M$’s OS to do all kinds of on-line and financial transactions.

    And Robert is called for a balk, and the batter walks.

    It’s nothing at all to do with any specific vendor whatsoever.

    Even Gnu/Linux cannot beat entropy.

  23. DrLoser says:

    Bing-a-Ling Loser rather read Monty Python history.

    Surprisingly eloquent, coming from you, Dougie. Now, about that naughty and triffically difficult entropy maths …

    Bruce Schneier wrote a book “Applied Cryptography” which discussed entropy in some depth and what happens when you don’t have it in passwords. The book is surprisingly accessable to non-specialists. I recommend it to all commentators on this topic.

    This is far more like it: at least ram knows how to cite a relevant authority. Schneier does, indeed, know his stuff. And as ram says, anything that he says is well worth reading.

    But … unfortunately not appropriate in this instance. Because we are not talking about cryptography.

    What we have here is something that is not merely unencrypted, in any meaningful sense, but is a (large) set not even disassociated from the input set. I’m going to try to make this plain by taking a few liberties and constructing a sort of 1968-style allocation of South Korean SSIDs.

    First, you have twelve digits to deal with. (10^12, for Dougie’s benefit.)

    a) Take one digit off for gender: M/F. Leaving eleven digits.
    b) Take three digits off for the day-of-year. Leaving eight digits.
    c) Take two digits off for year number. Leaving six digits.
    d) Take three digits off for my assumption that there are 1,000 prefectures or similar “places of birth.” Leaving three digits.

    Every single last one of those assumptions is factually incorrect. I am using them purely for example. To take the obvious case, one might encode “male” as 0 and “female” as “1”. This leaves log2(5) bits of entropy going spare.

    And who is to say, without examining the algorithm, that this is not precisely what the South Koreans did in 1968?

    Now, given those three spare digits. Like I say, there is no obvious reason to assume that they are randomised in any way. In fact, considering that the input is a simple counter of children born in one place in one day, I would expect that they are not.

    But it’s still a big ole 10^12 amount of entropy, isn’t it?

    No it is not.

    Figuring out your mark’s gender is trivial.

    Figuring out your mark’s date of birth is trivial.

    Figuring out where your mark was born … well, at worst you’d be left with maybe 10 out of 1000 prefectures.

    And on the assumption that the other parts are given a sequential ordering … and you could trivially check this by examining the SSIDs of a small set of people born on the same day in the same prefecture …

    You basically have no entropy left at all.

    I’m actually surprised I have to explain this elementary mathematics to you lot (excluding those who have not got a High School Equivalency, naturally).

    This has nothing at all to do with Microsoft, and everything to do with a pathetically easily cracked SSID system.

    Naturally, not a single one of you will admit this blatantly obvious fact.

  24. ram wrote, “entropy in some depth and what happens when you don’t have it in passwords”.

    There has been a lot of discussion of passwords in recent years. With the increasing power of computers the length of passwords has gone from a few characters to more than a dozen with little increase in security because an attacker only has to be lucky once to bring the house down. It’s likely that passwords will fade and be replaced by two(or more)-factor authentication and various tokens.

    I am reminded of a story told by my father from WWII. His battery had advanced from Normandy and were being shelled by the Germans from Dunkirk. A German plane was observed flying on a predictable schedule and route in and out of the port. Our guys were ordered not to fire on it lest we gave away our position. My dad and his buddies had managed to secure a few “unaccounted” anti-aircraft rounds and conspired to let loose one night. They did so and immediately swapped their hot barrel for a cold one in case any officer checked. That happened and the measure of feeling the temperature of the barrels was trivially defeated by the mischievous gun-crew. It’s the same with authentication. Whatever method can be devised can be circumvented or it will be so onerous the utility of IT will be degraded. The same goes for encryption or physical access to premises. There’s always a way through, even if it’s to pay spies/agents or just to wreck what can’t be stolen. The best we can do is add enough layers of security so that damage is limited or not worth the effort.

  25. dougman says:

    Bing-a-Ling Loser rather read Monty Python history.

  26. ram says:

    Bruce Schneier wrote a book “Applied Cryptography” which discussed entropy in some depth and what happens when you don’t have it in passwords. The book is surprisingly accessable to non-specialists. I recommend it to all commentators on this topic.

  27. DrLoser says:

    Now, about this “trap” you were talking about, Robert.

    On the basis here presented, there is no such thing, is there?

  28. DrLoser says:

    Here’s the interesting thing, Robert.

    I, anointed as a Microsoft Shill, read your post for the first time, and my immediate thought was “Oh Christ, Microsoft have stepped on their dicks again!”

    After all, in my limited 20% Microsoft spare time when I am not being a shill, I did things like worry about ActiveX, worry about secure transactions, worry about identity theft, worry about security surfaces … all that trivial stuff. And, be assured, us Microsoft Shills have a residue of professionalism which we try hard to pound down, yet it still occasionally surfaces.

    If this was a genuine Microsoft issue, and I could analyse it as such in my 20% Do Good Things time, then you can be assured that I would expose it as such.

    Sadly, all I have is a thorough reading of your cite, a secondary search for global identity theft numbers by country that unfortunately didn’t work, a search for details about how South Korean SSIDs are actually constructed, and a couple of ad-hoc calculations based upon the data found in half an hour of trawling.

    You should try being honest that way. It is invigorating. I speak as a Microsoft Shill.

    Disclaimer: No Gnu Software was harmed during the construction of this argument. I merely resorted to a calculator.

  29. DrLoser says:

    A rather large correction on that guess. Based upon the assumption of 1,000 prefectures or whatever a birthplace is called, I’ve now come up with around 14 bits of entropy per South Korean SSID, or a Gaussian Field of 20,000 possible unique identifiers.

    Which is still easily cracked, with an incredibly small amount of will-power and hardware. But at this level you’d be talking about cracking the SSID of “Robert d’Angevin Pogson-San,” not of cracking all 60-odd millions.

    Let us now make an assumption, based upon a brief examination of the available evidence. Those 14 bits aren’t allocated at random, are they? (After all, none of the other information is.)

    Perhaps they start at 0. Perhaps they start at 1. Perhaps some cunning fiend started them at 2^15 and counted backwards in threes … I somehow doubt that a hacker would find it difficult to suss out the pattern.

    So, mapping the sequence of allocated numbers to a set of easily checked instances — given a secondary calculation, not shown here, that one might need anywhere up to ten ordinals to count the number of babies in any given bucket — should be so utterly trivial as to require practically no skill whatsoever.

  30. DrLoser says:

    Yes, very interesting, Robert. Is (South) Korea more at risk from identity theft, on average, than any other part of the “Western” world? Who knows?

    As I might have pointed out, a big part of my work at Visa centred around this stuff. And you’ll be pleased to know that I advocated against the joint enterprise of Visa and Microsoft (and I seem to recall MasterCard) in the early days — which certainly included ActiveX. Although I’m not so sure that that is relevant, 15 years on.

    It does worry me that I can’t easily pull up statistics on global identity theft. You’d think this would be trivial. It isn’t. All help gratefully accepted.

    Anyhow, to the main issue of South Korean SSIDs, and from your cite:

    Part of the problem is the numbers themselves. The ID numbers aren’t randomized – they start with the owner’s birthdate, then have the digit one or two to indicate the recipient’s sex, then other numbers depending on where they are from. These numbers are used in everything from opening a bank account to getting an accredited email address.

    According to this site, the ID number has a length of 13 and the system has been around since 1968. Darn that Bill Gates and his time machine!

    Unfortunately, the way in which the 13 digit ID numbers are formulated make them easy to steal as they are all constructed in the same way, using numbers based upon the citizen’s date of birth, sex, place of birth and a sequential number used to identify those of the same sex who were born on the same day in the same location, as well as a check digit.

    Gotta love that check digit! Three more bits of entropy wasting away on the vine.

    Anyhoo … let’s play a little game and compete to see how much real entropy there is in one of these suckas, given the amount of other personal information available online.

    My guess (calculated as I would in a Microsoft Examination Question, a la How Would You Move Mount Fuji? is, ummmm … let’s see …

    Three or four.

    That’s not an extraordinarily difficult amount of entropy to hack, is it?

Leave a Reply