I have experienced the abuse you are talking about in one form or another too. And I'm a 35yrs old white male. So does this behaviour start from you being female or the fact that you (and me) know much more and make much more money than the people starting the abuse?
Yeah, because I'm sure that the engineering costs are small in order to build a new system and win 2-3 years of "opaqueness" until everybody gets accustomed to systemd.
1. The official site has nothing about it 2. Broadcom has nothing on their site about a BCM2836 3. On the register photo, there is no RAM on the PI (it should be on top of the processor)
Unethical? Whatever. Having read the original "census", it was a cool hack and no harm was done, nothing more. I'm pretty sure he/they didn't go for vigorous scientific process when this was done.
The difference is that OpenSSL provides a way to explicitly reseed the PRNG by calling RAND_poll. LibreSSL, unfortunately, has turned RAND_poll into a no-op (lines 77-81). fork_rand calls RAND_poll after forking, as do all my OpenSSL-using programs in production, which is why fork_rand is safe under OpenSSL but not LibreSSL.
The disclosure is very well written, says exactly why this is a big problem and proposes a very implementable solution that would fix it. Nevertheless, the dev decided to try to dismiss the disclosure, called his daddy (de Raadt) and they both threw a tantrum, and fixed it in a way that is questionable (an update on the disclosure raises some good questions on why it is questionable)
Btw, forgetting about ssl for a minute (open/libressl are crypto libraries, not ssl libraries), a PRNG is either secure or it is not. There is no "kinda" secure in most user scenarios etc.
the PIN vs signature subject (the cardholder verification methods) has more to do with who pays when the fraud happens. Signature is by far easier to use, and this is the reason why in europe it is usual for good customers (cards with expensive subscription fees etc.) to get chip and signature and low end cc and debit cards get chip and pin.
To me the problem is not the PIN, but the magstripe itself, which for europe is kept there for legacy reasons (and at this point, yes I am looking at you US...). If the magstripe was completely disabled then there would be no way to skim the card because you would lose one of the 2 required pieces of information (PAN/CVV).
The second problem is that even with the PAN/PIN, the card should be useless but again there are 2 problems.
1. is again legacy reasons. You steal the PAN, write it in a new card, enter the stolen PIN, bob's your uncle. This should not be possible if the cards where full EMV as the card itself is authenticated against Visa/Master PKI.
2. Internet purchases! Now this is a biggie. You don't want to inconvenience anyone so you keep it as easy as possible. No card authentication, no cardholder authentication. Everything goes. To me this problem can be best tackled with one time passwords/tokens generated by a smartcard.
As you understand this is not a technical problem - and I can assure you that the technology exists and it is solid, but an adoption problem and a backwards compatibility problem.
btw: Come on, you can't read Bruce Schneier and at the same time write the PIN on the back of the card. This is like writing your password on a postit and stick it on the screen. Sure, it's annoying but have some standards!
I don't have experience with the american market so your mile may vary. Having said that:
The terminals are usually sold by vendors that develop the software too. If a bank decides not to work with the vendor in order to develop the software (as in testing environments, proper specifications etc.) then you simply can't use a specific terminal device (reader if you like) with a specific bank/acquirer. As you understand this has to do more with business matters/politics, but nevertheless it is true.
Now the chip and pin/EMV vs magstripe only, if the bank doesn't support it, it is end of story which the OP mentioned. The specifications/requirements are simply too different.
Interestingly enough, EMV (c&p) cards work like this. However the card and the cardholder are both authenticated - either PIN or signature.
If someone steals your card, deactivate your card.
Ok, isn't it a bit stupid to design a system that can be circumvented by someone stealing your card? And no card deactivation for sure doesn't solve the problem
Not really. Chip might be kinda easy to read using commodity hardware, but pin entry must be done through a PCI certified device (as in, lots of money for certification, passed on to you, the consumer)
Ummmmm no. The wire protocols are de-facto standarized up to a point (ISO-8583 or vendor specific protocols) and the rest are application specific. Interestingly, wire protocols are one of the things that PCI has never touched.
The full PAN can and must be read from an EMV card. (EMV specifications, book 3, Mandatory data objects). Actually both the authentication and the card PAN are sent to the issuer.
I program on niche embedded devices which have 16mb of ram and still cost a lot of money for what they are. C is the only way there. However through the development circle we have a lot of bugs which get attributed to improper memory management - null dereferencing, memory leaks and the like. This makes the development circle longer, which is acceptable.
Now on the mobile market, it is an implied that the consumer prefers a lot of relatively stable applications in a short period of time. The tradeoff for this is to pay $20 more (probably much less) for the cost of doubling the RAM.
I think in the end, the problem is talent. Talent is scarce. It needs talent to program in C and it needs talent to design RAM modules. However RAM modules are designed once and then produced in an ultra massive scale. On the other side, every little bit of code needs a developer to work on it. And I know from experience that there isn't enough talent in C to produce the loads and loads of software that is currently produced - and even if there was, it would cost. So in the end I think the way it is, is the only way.
I'm known to be a low level person and professionally a C programmer. And I agree with you on some stuff.
However...
No, I won't use C to do something in 1k memory and 3 weeks of coding, I will use python in 10mb memory and 1 day of coding. Simply because my time costs more than 10mb of memory. So stop demonising higher level languages and accept that they have their perfectly legit uses as long as their limitations are undestood. Keep in mind that if android used C and not java, we would have about 5 non crashing apps tops in the market.
I'm pretty sure that even if they resolve everything, slashdotters will bitch about its color.
Nope. I spent good money on a handful of RPi's, wasted a few dozen hours on the beasts, just to finally turn up via searching specific error messages on Google that the USB/Ethernet stack is fatally crippled in design and that the GPU blob is secret-source and buggy and crashes on many media file decodes.
I have a raspi in front of me, with the embedded ethernet, 1 bluetooth, 2 wifi devices (1 master, 1 monitor), 1 gps, 2 usb sticks in raid, and it's charging my galaxy nexus through a powered hub. The usb problems have become such a chewing gum for the slammers, all I can say is: bullshit. You had a problem with an early revision of rpi and now you love bitching about it altough it is most probably resolved. You are welcome to post details though...
Now, for being a '21st Century C=64' and learning computing for school children, the thing is fine. The problem comes from all the geek-chic folks who are hocking the RPi for media center devices, network devices, and a replacement for microcontrollers.
I am guessing you were going to use it for rocket control of the next mission to mars and the bugs destroyed your dreams? At least these people build/hack/destroy something. All I can see from you is bitching.
Perhaps the next generation of Pi will be fine for them, but the dominant culture currently isn't hipster, it's "The First Rule of RPi Club is Don't Talk About the Bugs".
The bugs are fairly known, and there are a lot of differences between the revisions of the pi's. As I said, you had a bug and you just love to bitch about it till the end of time.
That just wastes the time and money of people who have been mislead, only to wind up on BBB, Arduino, Atom, or AMD-E to get something reliable going.
If there's a known-faulty part expect the engineers to tell each other about it. Geek-Culture Nerds - who knows, they probably have to check with their self-appoint high priests to see what's cool today.
Again. Sorry for delaying your rocket control project.
Sure it is. I don't see you bitching about your phone, pc, car, tv, microwave oven though. You do realise that after this announcement, videocore is the most open core on an ARM chip ever, right?
At this point, I have concluded that many slashdotters are "hipster geeks"
Anything that gains traction and is widely known outside of the normal geek circles becomes "uncool" and is slammed down. As you can see for raspberry, although the things to bitch about are getting fewer and fewer, there are always things that slashdotters bitch about. I'm pretty sure that even if they resolve everything, slashdotters will bitch about its color.
Now think what would happen if only a couple of thousand raspis were sold and only part of the geek community knew about it. It would be all the rage!
PEDs (pin entering devices) are heavily regulated and certified by visa and mastercard (PCI standards) so it's nearly impossible to intercept the pin before being encrypted. It is done in hardware by special purpose cryptoprocessors. Track2 data however can be stolen.
The problem lies that issuing banks should not accept transactions which are not authenticated by the chip as genuine. This is usually hard because of legacy infrastructure that can't handle it, or that they don't want to lose the transaction. After all, lost revenue might be higher than the fraud loses.
If all measures are applied as they are specified, fraud should be very close to zero. Believe me, the people who specified these standards and protocols are quite smart. However banks are very slow moving beasts and replacing all the infrastructure and re-training everyone to hard to understand concepts is costly enough that some fraud can be tolerated
You have a point that the liability is moved from the merchant (If he didn't verify the signature) to the cardholder. You also have a point that you can bypass a check with a MITM attack (not exactly practical)
However magstripes are copiable. Chips are not. The are personalised with a PKI which starts from the card system (visa/master) and the terminal always authenticates that the card is authentic against public keys. Properly configured issuers do not allow a transaction if it is not accompanied by a crypto signature by the card containing the amount, merchant ID etc. so you can't just copy the magstripe and do a transaction like this
These are just some of the _technical_ points why chip is more secure. Now, I know you want to bitch about how the banks are screwing us over, and you may be right about it, but your reasoning isn't
Have you realised that you posted the official raspberry pi foundation github account as a reverse engineering proof? They are doing many things, but reverse engineering is not one of them.
Also, I don't think anybody needs proof. It is common knowledge...
TI fully documents their system on chip (SOC) chips.
Sure. Could you please send us a reference of the SGX530 which is the GPU in beagleboard? And the kernel drivers that interface with the blob doesn't count, obviously.
I mean, I like a good argument, but pleeease try to check your facts first.
Slashdot Mirror
I have experienced the abuse you are talking about in one form or another too. And I'm a 35yrs old white male. So does this behaviour start from you being female or the fact that you (and me) know much more and make much more money than the people starting the abuse?
Just sayin'
Yeah, because I'm sure that the engineering costs are small in order to build a new system and win 2-3 years of "opaqueness" until everybody gets accustomed to systemd.
obligatory...
I'm I the only one that has noticed that:
1. The official site has nothing about it
2. Broadcom has nothing on their site about a BCM2836
3. On the register photo, there is no RAM on the PI (it should be on top of the processor)
and many many more little things
Unethical? Whatever.
Having read the original "census", it was a cool hack and no harm was done, nothing more. I'm pretty sure he/they didn't go for vigorous scientific process when this was done.
From the disclosure:
The difference is that OpenSSL provides a way to explicitly reseed the PRNG by calling RAND_poll. LibreSSL, unfortunately, has turned RAND_poll into a no-op (lines 77-81). fork_rand calls RAND_poll after forking, as do all my OpenSSL-using programs in production, which is why fork_rand is safe under OpenSSL but not LibreSSL.
Just sayin'....
Exactly!
The disclosure is very well written, says exactly why this is a big problem and proposes a very implementable solution that would fix it. Nevertheless, the dev decided to try to dismiss the disclosure, called his daddy (de Raadt) and they both threw a tantrum, and fixed it in a way that is questionable (an update on the disclosure raises some good questions on why it is questionable)
Btw, forgetting about ssl for a minute (open/libressl are crypto libraries, not ssl libraries), a PRNG is either secure or it is not. There is no "kinda" secure in most user scenarios etc.
the PIN vs signature subject (the cardholder verification methods) has more to do with who pays when the fraud happens. Signature is by far easier to use, and this is the reason why in europe it is usual for good customers (cards with expensive subscription fees etc.) to get chip and signature and low end cc and debit cards get chip and pin.
To me the problem is not the PIN, but the magstripe itself, which for europe is kept there for legacy reasons (and at this point, yes I am looking at you US...). If the magstripe was completely disabled then there would be no way to skim the card because you would lose one of the 2 required pieces of information (PAN/CVV).
The second problem is that even with the PAN/PIN, the card should be useless but again there are 2 problems.
1. is again legacy reasons. You steal the PAN, write it in a new card, enter the stolen PIN, bob's your uncle. This should not be possible if the cards where full EMV as the card itself is authenticated against Visa/Master PKI.
2. Internet purchases! Now this is a biggie. You don't want to inconvenience anyone so you keep it as easy as possible. No card authentication, no cardholder authentication. Everything goes. To me this problem can be best tackled with one time passwords/tokens generated by a smartcard.
As you understand this is not a technical problem - and I can assure you that the technology exists and it is solid, but an adoption problem and a backwards compatibility problem.
btw: Come on, you can't read Bruce Schneier and at the same time write the PIN on the back of the card. This is like writing your password on a postit and stick it on the screen. Sure, it's annoying but have some standards!
I don't have experience with the american market so your mile may vary. Having said that:
The terminals are usually sold by vendors that develop the software too. If a bank decides not to work with the vendor in order to develop the software (as in testing environments, proper specifications etc.) then you simply can't use a specific terminal device (reader if you like) with a specific bank/acquirer. As you understand this has to do more with business matters/politics, but nevertheless it is true.
Now the chip and pin/EMV vs magstripe only, if the bank doesn't support it, it is end of story which the OP mentioned. The specifications/requirements are simply too different.
Interestingly enough, EMV (c&p) cards work like this. However the card and the cardholder are both authenticated - either PIN or signature.
If someone steals your card, deactivate your card.
Ok, isn't it a bit stupid to design a system that can be circumvented by someone stealing your card? And no card deactivation for sure doesn't solve the problem
Not really. Chip might be kinda easy to read using commodity hardware, but pin entry must be done through a PCI certified device (as in, lots of money for certification, passed on to you, the consumer)
https://www.pcisecuritystandar...
Because bitcoin is totally fraud-proof.
Ummmmm no.
The wire protocols are de-facto standarized up to a point (ISO-8583 or vendor specific protocols) and the rest are application specific. Interestingly, wire protocols are one of the things that PCI has never touched.
No....
The full PAN can and must be read from an EMV card. (EMV specifications, book 3, Mandatory data objects). Actually both the authentication and the card PAN are sent to the issuer.
Completely generic? Ummmm no. They are C programmable embedded devices which are usually developed according to the acquiring bank's specifications.
Where were you looking? I can't find a usb to serial that doesn't support 1200 baud. And I work with them all day every day.
I program on niche embedded devices which have 16mb of ram and still cost a lot of money for what they are. C is the only way there. However through the development circle we have a lot of bugs which get attributed to improper memory management - null dereferencing, memory leaks and the like. This makes the development circle longer, which is acceptable.
Now on the mobile market, it is an implied that the consumer prefers a lot of relatively stable applications in a short period of time. The tradeoff for this is to pay $20 more (probably much less) for the cost of doubling the RAM.
I think in the end, the problem is talent. Talent is scarce. It needs talent to program in C and it needs talent to design RAM modules. However RAM modules are designed once and then produced in an ultra massive scale. On the other side, every little bit of code needs a developer to work on it. And I know from experience that there isn't enough talent in C to produce the loads and loads of software that is currently produced - and even if there was, it would cost. So in the end I think the way it is, is the only way.
I'm known to be a low level person and professionally a C programmer. And I agree with you on some stuff.
However...
No, I won't use C to do something in 1k memory and 3 weeks of coding, I will use python in 10mb memory and 1 day of coding. Simply because my time costs more than 10mb of memory. So stop demonising higher level languages and accept that they have their perfectly legit uses as long as their limitations are undestood. Keep in mind that if android used C and not java, we would have about 5 non crashing apps tops in the market.
Sooo, yeah...
It's not about stupidity, anonymous troll. It's about time having some actual value.
I'm pretty sure that even if they resolve everything, slashdotters will bitch about its color.
Nope. I spent good money on a handful of RPi's, wasted a few dozen hours on the beasts, just to finally turn up via searching specific error messages on Google that the USB/Ethernet stack is fatally crippled in design and that the GPU blob is secret-source and buggy and crashes on many media file decodes.
I have a raspi in front of me, with the embedded ethernet, 1 bluetooth, 2 wifi devices (1 master, 1 monitor), 1 gps, 2 usb sticks in raid, and it's charging my galaxy nexus through a powered hub. The usb problems have become such a chewing gum for the slammers, all I can say is: bullshit. You had a problem with an early revision of rpi and now you love bitching about it altough it is most probably resolved. You are welcome to post details though...
Now, for being a '21st Century C=64' and learning computing for school children, the thing is fine. The problem comes from all the geek-chic folks who are hocking the RPi for media center devices, network devices, and a replacement for microcontrollers.
I am guessing you were going to use it for rocket control of the next mission to mars and the bugs destroyed your dreams? At least these people build/hack/destroy something. All I can see from you is bitching.
Perhaps the next generation of Pi will be fine for them, but the dominant culture currently isn't hipster, it's "The First Rule of RPi Club is Don't Talk About the Bugs".
The bugs are fairly known, and there are a lot of differences between the revisions of the pi's. As I said, you had a bug and you just love to bitch about it till the end of time.
That just wastes the time and money of people who have been mislead, only to wind up on BBB, Arduino, Atom, or AMD-E to get something reliable going.
If there's a known-faulty part expect the engineers to tell each other about it. Geek-Culture Nerds - who knows, they probably have to check with their self-appoint high priests to see what's cool today.
Again. Sorry for delaying your rocket control project.
Hackers hack. Bitches bitch. Choose wisely...
Sure it is. I don't see you bitching about your phone, pc, car, tv, microwave oven though. You do realise that after this announcement, videocore is the most open core on an ARM chip ever, right?
btw, http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf here you go...hack away
At this point, I have concluded that many slashdotters are "hipster geeks"
Anything that gains traction and is widely known outside of the normal geek circles becomes "uncool" and is slammed down. As you can see for raspberry, although the things to bitch about are getting fewer and fewer, there are always things that slashdotters bitch about. I'm pretty sure that even if they resolve everything, slashdotters will bitch about its color.
Now think what would happen if only a couple of thousand raspis were sold and only part of the geek community knew about it. It would be all the rage!
PEDs (pin entering devices) are heavily regulated and certified by visa and mastercard (PCI standards) so it's nearly impossible to intercept the pin before being encrypted. It is done in hardware by special purpose cryptoprocessors. Track2 data however can be stolen.
The problem lies that issuing banks should not accept transactions which are not authenticated by the chip as genuine. This is usually hard because of legacy infrastructure that can't handle it, or that they don't want to lose the transaction. After all, lost revenue might be higher than the fraud loses.
If all measures are applied as they are specified, fraud should be very close to zero. Believe me, the people who specified these standards and protocols are quite smart. However banks are very slow moving beasts and replacing all the infrastructure and re-training everyone to hard to understand concepts is costly enough that some fraud can be tolerated
No. Please don't spread FUD
You have a point that the liability is moved from the merchant (If he didn't verify the signature) to the cardholder. You also have a point that you can bypass a check with a MITM attack (not exactly practical)
However magstripes are copiable. Chips are not. The are personalised with a PKI which starts from the card system (visa/master) and the terminal always authenticates that the card is authentic against public keys. Properly configured issuers do not allow a transaction if it is not accompanied by a crypto signature by the card containing the amount, merchant ID etc. so you can't just copy the magstripe and do a transaction like this
These are just some of the _technical_ points why chip is more secure. Now, I know you want to bitch about how the banks are screwing us over, and you may be right about it, but your reasoning isn't
The fact that there are significant reverse-engineering efforts going on
https://github.com/raspberrypi/firmware/wiki
https://github.com/hermanhermitage/videocoreiv/
is proof that the Broadcom chip in the Raspberry Pi is anything but open.
Have you realised that you posted the official raspberry pi foundation github account as a reverse engineering proof? They are doing many things, but reverse engineering is not one of them.
Also, I don't think anybody needs proof. It is common knowledge...
TI fully documents their system on chip (SOC) chips.
Sure. Could you please send us a reference of the SGX530 which is the GPU in beagleboard? And the kernel drivers that interface with the blob doesn't count, obviously.
I mean, I like a good argument, but pleeease try to check your facts first.