I work in the smartcard industry and most of the time those "breaks" mean nothing: usually the "hacker" simply reads the publicly available information and claims that the system is "broken". The reaction of the public is always interesting and shows that many users do not understand the goals of such a system, probably because the politicians that buy those systems do not explain them very well.
However in this case the article claims that they were able to clone the card AND modify the information in the cloned card, which is really the hack that those cards are trying to prevent. This article is heavier on details than many others and that makes it more credible, but the details are still muddy. I hope that the journalist missed a crucial point and that this card is not as insecure as he thinks.
Small-scale, private smartcard-based systems can be cracked, usually because they are badly installed and used. Large-scale, private smartcard-based systems can be cracked (just look into the MiFare Classic debacle) but it involves months of hard work from people with PhDs and access to expensive equipement. Large-scale, govermental smartcard-based systems can be cracked, but I would be really surprised if it took only a few minutes. Unless that hacker presents the attack in details, I will file this one in the "baseless fearmongering in order to sell more papers" folder (which is already bursting BTW).
The power adaptor is made to recharge the battery. The battery can provide a higher wattage to the computer and thus power it properly. Using the adaptor to power the computer is misuse of the adaptor.
Then how does the power adaptor manage to power AND recharge the battery at the same time? It certainly worked for every laptop I had. If the power adaptor was not strong enough to do that, one would have to leave the laptog plugged all night to recharge the battery because at the end of the day the battery would be exhausted.
If this is really what you meant, you should try to learn more about batteries and laptops.
Actually, the crumple zones saved both of them: they dissipated the kinetic energy of the whole impact. This guy was able to walk away from the accident BECAUSE the other guy was driving a car with crumple zones. This is also the reason why the car was demolished instead of simply taking a hit.
If the other guy had been driving a steel car too, he wouldn't be posting on/. today.
... since it was expensive as hell. Small notebooks have existed for a long time. The novelty of the Asus EEEPC was that it was cheap (and flimsy): it demonstrated that there was an untapped market for this kind of computers.
The Unix Way is a perfectly valid method to develop administrative, text-based tasks targeting a single, well-known platform, but does not scale well toward the development of other types of applications.
First, compared to modern languages like Python or Java, shell scripting sucks. The syntax is awkward and it can only manipulate bits of text. The world has moved on from text. Today, I want to be able to process complex structures, which in many cases cannot be converted to a simple text format.
Second, modern languages have huge libraries, so usually there is no need to use anything but those libraries. Furthermore, using those libraries reduced compatibilities issues. When I develop for the Java 6 platform, I know the code is going to work on every single platform with support for Java 6: Windows, Linux, Solaris, you name it. With the Unix Way, you have to make sure that every single function of every single tool you use is going to behave in the same way on every single platform. This is of course a huge pain in the ass.
But there is no need to fret. You quote Python: from my point of view, it is one of the platforms that can be used exclusively, so your experience is perfectly valuable. Regexp are pretty much the same everywhere.
But I do not really understand your problem. If you're developing applications, you should know all that already. If your software development experience is limited to administering systems, shell scripting is always going to work for you. I guess that in this last case, you may want to try to pick a singe platform (say, Python) for all your dev needs and see how it goes.
This kind of things can happen to every company, true. However, this seems to happen to Microsoft a lot... And in many of those cases, it was proven that Microsoft knew about the issue but decided to release the product anyway: the bugs in Windows Vista, the Red Ring of Death of the Xbox... Please note that is not a criticism of the Microsoft employees but of the corporate cultural at the executive level that lead them to those issues.
There is only one thing that pisses me off with Amazon: the package they use for sets of large/heavy books is inadequate. Every single Peanuts Boxset I've ordered was dented, bruised or scratched. Same thing for "coffee-table" books. Oh yeah, sure, I can return the item for a refund or a replacement, no questions asks, but 1) returning things is annoying and takes time and 2) the returned book will be destroyed, which is complete waste of a perfectly good book. I bet that someone at Amazon has an Excel spreadsheet showing exactly what kind of cardboard they should use to minimize the number of returns while maximizing the profits, and I'm sure that this spreadsheet takes into the account the fact that most people with accept a certain level of damage.
Hopefully, there is a solution: make a specific order for each "large/heavy" item. The packaging they use to send a single book is usually alright.
That's why I write all my documents on blank paper with a Bic pen. Now I'll grant you that encrypting and decrypting those documents is a pain. Oh well, at least they are secure.
My parents had only a checking acount, savings account, and credit card.
In many developed countries (Europe, Japan,...), many people have a single account which supports both checks and debit cards. Mine is also used as a brokerage account, but I'm probably not a typical client.
I tried the demo over at javafx.com and I got two security warnings (they use self-signed certificates) and one popup with a EULA. And the demo have some serious usability and display issues.
I love Java and it pays my bills but Sun really have a long way to go to reach the acceptance level of Flash.
The second link is an "Analysis of an Electronic Voting System" so it has nothing to do with the security of smartcards per se. If Diebold doesn't know how to implement a secure voting system, this cannot be blamed on smartcards.
Read down to the third section. Hint: the title of the section is "Smartcards" and goes into reasonable detail about "smartcard-based attacks against the voting terminals".
I did. The last paragraph says it all:
Diebold uses an insecure protocol that makes them vulnerable to counterfeit smartcards. Modern smartcards can perform cryptographic operations, allowing for more sophisticated protocols. If Diebold used such protocols, their system would be robust against our attacks.
In other words, Diebold picked an insecure protocol to communicate with its smartcards. This cannot be blamed on smartcards or on the smartcards industry (Diebold does not belong to this industry).
The third link points to a PR from the Smart Card Alliance ("a nonprofit industry body representing several large vendors of smart-card and RFID technologies") pointing out flaws in the government plans for RFID passports. That's a pretty responsible move for an industry body that's supposed to lobby on behalf on its constituents.
Responsible, yes... "Here's a bunch of valid reasons why our technology is entirely unsuitable for the intended purpose, which we ought to point out before someone outside the loop figures it out anyway." Kudos to them for coming clean, but it still doesn't get them any closer to actually finding a viable solution to the problem.
Solutions do exist. However, for unknown reasons, some governments decided not to use them. The US governement is one of the them.
Sure, this is pretty much the system I describe in the second part of my post. However, my point was that you need to store something in the card that tell the turnstile whether the card is valid or not: you do not want to admit someone because he presents a generic RFID card to the turnstile. And this exchange must be authenticated to detect fake cards right away. If the cards are not authenticated but simply detected after the fact and placed on a hot list, a cracker simply have to generate a new card every day.
Mifare cards can be bought online for a few dollars, from perfectly legit shops. The only difference between a generic Mifare card and an Oyster card is that the encryption keys for the Oyster network are not loaded in a generic Mifare cards.
The first link is related to the Mifare hack. Mifare cards are insecure, this has been known for a long time. Now I will grant you that the response from the MTBA and NXP have been distateful but predictable.
The second link is an "Analysis of an Electronic Voting System" so it has nothing to do with the security of smartcards per se. If Diebold doesn't know how to implement a secure voting system, this cannot be blamed on smartcards.
The third link points to a PR from the Smart Card Alliance ("a nonprofit industry body representing several large vendors of smart-card and RFID technologies") pointing out flaws in the government plans for RFID passports. That's a pretty responsible move for an industry body that's supposed to lobby on behalf on its constituents.
Rule 1: Never trust the client. Rule 2: Never trust the client. Rule 3: Never, ever, ever, trust the client.
This is a good rule when the customer can do whatever he wants with the client, including reading and modifying values in memory. So this is true for PCs. Smartcards are different in the sense that they are designed to prevent the customer from accessing and modifying the content of the card. Of course, given enough time and money, everything can be cracked. Now, in some cases it is possible that the convenience of storing the data locally, in the chip, outweighs the risks. The people in charge of the deployment of the Oyster card misjuged the risk associated with Mifare cards and are now paying the price.
Anyone with an RFID reader/writer and enough time could modify their card to report whatever balance they want.
This is only true for Mifare Classic cards, which is the type of cards used in London. Transportation systems that do not use Mifare Classic cards are totally unaffected by this hack.
Oh wait, it already happened. It's why the old company was being dumped.
Actually, they aren't. It seems that they only dumped two consultants. Furthermore, the company that manufactures the Mifare cards (NXP) was not even a part of this consortium. Also the company in charge of the procurement of the card is still there. Finally, switching to another type of card would be extremelly expensive. They are simply going to use the newer Mifare Plus cards that relies on 3DES. Mifare cards with support for DES and 3DES have been available for a while, it's just that they are a bit more expensive than Mifare Classic cards.
1. Anyone capable of altering the card can give themselves free unlimited travel.
Yeah, sure. That's why transport operators with half a clue use standard cryptographic algorithms to protect the content of their cards instead of proprietary, unpublished algorithms like the Oyster card.
2. If the card is damaged to the point where it no longer works, you lose your remaining balance.
Storing the data in the card does not prevent you from mirroring it on a server.
The objections you rise are valid. Thankfully the smartcard industry knows how to handle them.
Well, with a server-side solution, you just have to make sure that every turnstile can call a central server and process a transaction in less than 200ms. This includes the turnstiles in buses and in remote locations...
Truth is, every transportation system with more than a few fixed turnstile stores the rights of the user locally, in the smartcard chip. Of course, transactions logs are analysed every night and it is usually possible to detect incoherences between the values stored in the card and the reference value stored in the server. In that case, the ID of the misbehaving card is placed on a "hot list" and the card cannot be used anymore.
Of course, this works only if you use real cryptographic algorithms (like 3DES or AES) to protect the content of the card instead of relying on a vendor's snake oil.
For example, Airline reservation systems. Or Slashdot. Or anything web-based. Or your Visa card, Mastercard, ATM card. Strange how effective those electronic debit machines are, even though they assume 100% uptime of the Visa/MC/Debit back end systems? What about your phone? Doesn't it assume 100% uptime of the call routers and connection?
Actually, all those systems assume that the network will be down "sometimes" and have build-in mechanisms to deal with them. In some cases, there is no solution but to wait for the affected service to come back: my browser did not went dead during the Great Slashdot Blackout. In some other cases, they can continue to work in a degraded mode. For example, a merchant can accept credit and debit card "offline" and process them later. The risks are far greater than processing cards "online" but, hey, the merchant can still sell stuff even if the network is down. Same thing for ATMs: if the network is down, they will still accept cards but will only distribute small amounts of money.
The case for phones is more interesting. The introduction of VOIP actually degraded the reliability of fixed-lines phones, including the reliability of emergency calls. VOIP operators usually weasel out of this mess by stating that "everyone has a cell phone now."
Providing a 99.999% uptime is really expensive. Furthermore, in most cases you can't control every other point in the delivery chain (the network, the other participants' servers...), so a service must be able to deal with downtime. It seems possible to configure some BD players to prevent the disc to download new content. If the Ironman BD cannot run in this case, well that's just means that the application on the disc was not correctly tested.
Well, it's true that RFID passports are of a limited interest for an individual, but don't you think that making passports harder to clone or to forge is good for everyone in the long term?
Actually, I consulted with them for about a month and my responsability was very limited so from my point of view it was just funny. I check their website from time to time to see if they've finally managed to release the product. Of course some of their programmers already left, but the remainings are H1-Bs... Good luck on your next job.
I worked with a US company were the ratio was 6:1. Yes, about 6 managers for 1 programmer (they had 3). They've been working on their (not so complicated) product for about 4 years, with no end in sight.
Slashdot Mirror
I work in the smartcard industry and most of the time those "breaks" mean nothing: usually the "hacker" simply reads the publicly available information and claims that the system is "broken". The reaction of the public is always interesting and shows that many users do not understand the goals of such a system, probably because the politicians that buy those systems do not explain them very well.
However in this case the article claims that they were able to clone the card AND modify the information in the cloned card, which is really the hack that those cards are trying to prevent. This article is heavier on details than many others and that makes it more credible, but the details are still muddy. I hope that the journalist missed a crucial point and that this card is not as insecure as he thinks.
Small-scale, private smartcard-based systems can be cracked, usually because they are badly installed and used. Large-scale, private smartcard-based systems can be cracked (just look into the MiFare Classic debacle) but it involves months of hard work from people with PhDs and access to expensive equipement. Large-scale, govermental smartcard-based systems can be cracked, but I would be really surprised if it took only a few minutes. Unless that hacker presents the attack in details, I will file this one in the "baseless fearmongering in order to sell more papers" folder (which is already bursting BTW).
Then how does the power adaptor manage to power AND recharge the battery at the same time? It certainly worked for every laptop I had. If the power adaptor was not strong enough to do that, one would have to leave the laptog plugged all night to recharge the battery because at the end of the day the battery would be exhausted.
If this is really what you meant, you should try to learn more about batteries and laptops.
This blog chronicles the failure of this project: http://limuxwatch.blogspot.com/
A reference, please.
Actually, the crumple zones saved both of them: they dissipated the kinetic energy of the whole impact. This guy was able to walk away from the accident BECAUSE the other guy was driving a car with crumple zones. This is also the reason why the car was demolished instead of simply taking a hit.
If the other guy had been driving a steel car too, he wouldn't be posting on /. today.
... since it was expensive as hell. Small notebooks have existed for a long time. The novelty of the Asus EEEPC was that it was cheap (and flimsy): it demonstrated that there was an untapped market for this kind of computers.
The Unix Way is a perfectly valid method to develop administrative, text-based tasks targeting a single, well-known platform, but does not scale well toward the development of other types of applications.
First, compared to modern languages like Python or Java, shell scripting sucks. The syntax is awkward and it can only manipulate bits of text. The world has moved on from text. Today, I want to be able to process complex structures, which in many cases cannot be converted to a simple text format.
Second, modern languages have huge libraries, so usually there is no need to use anything but those libraries. Furthermore, using those libraries reduced compatibilities issues. When I develop for the Java 6 platform, I know the code is going to work on every single platform with support for Java 6: Windows, Linux, Solaris, you name it. With the Unix Way, you have to make sure that every single function of every single tool you use is going to behave in the same way on every single platform. This is of course a huge pain in the ass.
But there is no need to fret. You quote Python: from my point of view, it is one of the platforms that can be used exclusively, so your experience is perfectly valuable. Regexp are pretty much the same everywhere.
But I do not really understand your problem. If you're developing applications, you should know all that already. If your software development experience is limited to administering systems, shell scripting is always going to work for you. I guess that in this last case, you may want to try to pick a singe platform (say, Python) for all your dev needs and see how it goes.
This kind of things can happen to every company, true. However, this seems to happen to Microsoft a lot... And in many of those cases, it was proven that Microsoft knew about the issue but decided to release the product anyway: the bugs in Windows Vista, the Red Ring of Death of the Xbox... Please note that is not a criticism of the Microsoft employees but of the corporate cultural at the executive level that lead them to those issues.
There is only one thing that pisses me off with Amazon: the package they use for sets of large/heavy books is inadequate. Every single Peanuts Boxset I've ordered was dented, bruised or scratched. Same thing for "coffee-table" books. Oh yeah, sure, I can return the item for a refund or a replacement, no questions asks, but 1) returning things is annoying and takes time and 2) the returned book will be destroyed, which is complete waste of a perfectly good book. I bet that someone at Amazon has an Excel spreadsheet showing exactly what kind of cardboard they should use to minimize the number of returns while maximizing the profits, and I'm sure that this spreadsheet takes into the account the fact that most people with accept a certain level of damage.
Hopefully, there is a solution: make a specific order for each "large/heavy" item. The packaging they use to send a single book is usually alright.
That's why I write all my documents on blank paper with a Bic pen. Now I'll grant you that encrypting and decrypting those documents is a pain. Oh well, at least they are secure.
I keep my sensitive documents in a locked cabinet. Never had an issue with a document opening itself in a foreign country.
My parents had only a checking acount, savings account, and credit card.
In many developed countries (Europe, Japan, ...), many people have a single account which supports both checks and debit cards. Mine is also used as a brokerage account, but I'm probably not a typical client.
Strangers In Paradise.
I tried the demo over at javafx.com and I got two security warnings (they use self-signed certificates) and one popup with a EULA. And the demo have some serious usability and display issues.
I love Java and it pays my bills but Sun really have a long way to go to reach the acceptance level of Flash.
The second link is an "Analysis of an Electronic Voting System" so it has nothing to do with the security of smartcards per se. If Diebold doesn't know how to implement a secure voting system, this cannot be blamed on smartcards.
Read down to the third section. Hint: the title of the section is "Smartcards" and goes into reasonable detail about "smartcard-based attacks against the voting terminals".
I did. The last paragraph says it all :
Diebold uses an insecure protocol that makes them vulnerable to counterfeit smartcards. Modern smartcards can perform cryptographic operations, allowing for more sophisticated protocols. If Diebold used such protocols, their system would be robust against our attacks.
In other words, Diebold picked an insecure protocol to communicate with its smartcards. This cannot be blamed on smartcards or on the smartcards industry (Diebold does not belong to this industry).
The third link points to a PR from the Smart Card Alliance ("a nonprofit industry body representing several large vendors of smart-card and RFID technologies") pointing out flaws in the government plans for RFID passports. That's a pretty responsible move for an industry body that's supposed to lobby on behalf on its constituents.
Responsible, yes... "Here's a bunch of valid reasons why our technology is entirely unsuitable for the intended purpose, which we ought to point out before someone outside the loop figures it out anyway." Kudos to them for coming clean, but it still doesn't get them any closer to actually finding a viable solution to the problem.
Solutions do exist. However, for unknown reasons, some governments decided not to use them. The US governement is one of the them.
Sure, this is pretty much the system I describe in the second part of my post. However, my point was that you need to store something in the card that tell the turnstile whether the card is valid or not: you do not want to admit someone because he presents a generic RFID card to the turnstile. And this exchange must be authenticated to detect fake cards right away. If the cards are not authenticated but simply detected after the fact and placed on a hot list, a cracker simply have to generate a new card every day.
Mifare cards can be bought online for a few dollars, from perfectly legit shops. The only difference between a generic Mifare card and an Oyster card is that the encryption keys for the Oyster network are not loaded in a generic Mifare cards.
The first link is related to the Mifare hack. Mifare cards are insecure, this has been known for a long time. Now I will grant you that the response from the MTBA and NXP have been distateful but predictable.
The second link is an "Analysis of an Electronic Voting System" so it has nothing to do with the security of smartcards per se. If Diebold doesn't know how to implement a secure voting system, this cannot be blamed on smartcards.
The third link points to a PR from the Smart Card Alliance ("a nonprofit industry body representing several large vendors of smart-card and RFID technologies") pointing out flaws in the government plans for RFID passports. That's a pretty responsible move for an industry body that's supposed to lobby on behalf on its constituents.
The last links is identical to the second link.
Rule 1: Never trust the client.
Rule 2: Never trust the client.
Rule 3: Never, ever, ever, trust the client.
This is a good rule when the customer can do whatever he wants with the client, including reading and modifying values in memory. So this is true for PCs. Smartcards are different in the sense that they are designed to prevent the customer from accessing and modifying the content of the card. Of course, given enough time and money, everything can be cracked. Now, in some cases it is possible that the convenience of storing the data locally, in the chip, outweighs the risks. The people in charge of the deployment of the Oyster card misjuged the risk associated with Mifare cards and are now paying the price.
Anyone with an RFID reader/writer and enough time could modify their card to report whatever balance they want.
This is only true for Mifare Classic cards, which is the type of cards used in London. Transportation systems that do not use Mifare Classic cards are totally unaffected by this hack.
Oh wait, it already happened. It's why the old company was being dumped.
Actually, they aren't. It seems that they only dumped two consultants. Furthermore, the company that manufactures the Mifare cards (NXP) was not even a part of this consortium. Also the company in charge of the procurement of the card is still there. Finally, switching to another type of card would be extremelly expensive. They are simply going to use the newer Mifare Plus cards that relies on 3DES. Mifare cards with support for DES and 3DES have been available for a while, it's just that they are a bit more expensive than Mifare Classic cards.
1. Anyone capable of altering the card can give themselves free unlimited travel.
Yeah, sure. That's why transport operators with half a clue use standard cryptographic algorithms to protect the content of their cards instead of proprietary, unpublished algorithms like the Oyster card.
2. If the card is damaged to the point where it no longer works, you lose your remaining balance.
Storing the data in the card does not prevent you from mirroring it on a server.
The objections you rise are valid. Thankfully the smartcard industry knows how to handle them.
Well, with a server-side solution, you just have to make sure that every turnstile can call a central server and process a transaction in less than 200ms. This includes the turnstiles in buses and in remote locations...
Truth is, every transportation system with more than a few fixed turnstile stores the rights of the user locally, in the smartcard chip. Of course, transactions logs are analysed every night and it is usually possible to detect incoherences between the values stored in the card and the reference value stored in the server. In that case, the ID of the misbehaving card is placed on a "hot list" and the card cannot be used anymore.
Of course, this works only if you use real cryptographic algorithms (like 3DES or AES) to protect the content of the card instead of relying on a vendor's snake oil.
Why is it incredibly studid?
For example, Airline reservation systems. Or Slashdot. Or anything web-based. Or your Visa card, Mastercard, ATM card. Strange how effective those electronic debit machines are, even though they assume 100% uptime of the Visa/MC/Debit back end systems? What about your phone? Doesn't it assume 100% uptime of the call routers and connection?
Actually, all those systems assume that the network will be down "sometimes" and have build-in mechanisms to deal with them. In some cases, there is no solution but to wait for the affected service to come back: my browser did not went dead during the Great Slashdot Blackout. In some other cases, they can continue to work in a degraded mode. For example, a merchant can accept credit and debit card "offline" and process them later. The risks are far greater than processing cards "online" but, hey, the merchant can still sell stuff even if the network is down. Same thing for ATMs: if the network is down, they will still accept cards but will only distribute small amounts of money.
The case for phones is more interesting. The introduction of VOIP actually degraded the reliability of fixed-lines phones, including the reliability of emergency calls. VOIP operators usually weasel out of this mess by stating that "everyone has a cell phone now."
Providing a 99.999% uptime is really expensive. Furthermore, in most cases you can't control every other point in the delivery chain (the network, the other participants' servers...), so a service must be able to deal with downtime. It seems possible to configure some BD players to prevent the disc to download new content. If the Ironman BD cannot run in this case, well that's just means that the application on the disc was not correctly tested.
Well, it's true that RFID passports are of a limited interest for an individual, but don't you think that making passports harder to clone or to forge is good for everyone in the long term?
Actually, I consulted with them for about a month and my responsability was very limited so from my point of view it was just funny. I check their website from time to time to see if they've finally managed to release the product. Of course some of their programmers already left, but the remainings are H1-Bs... Good luck on your next job.
I worked with a US company were the ratio was 6:1. Yes, about 6 managers for 1 programmer (they had 3). They've been working on their (not so complicated) product for about 4 years, with no end in sight.