Well, they needed to get to the chip first, then they would have a pretty good microscope (not your default kind of thingy) and they their attack might work. But nowadays most of the keys are stored encrypted with another (symetric) key that is not stored in main memory. Other kinds of memory are much harder to read. Note that this article has been published in 2002 and still smart card IC's get a CC AEL4+ rating. Not to say that there are no problems - attacking a chip with this attack has a much higher success rate than attacking an RSA key with any length over 512 bits. But this attack would at least be rather much for a car thief, even one that has a big criminal network behind it.
There are many USB tokens on the market. Probably a few of them will handle 2048 bit RSA keys. This is as strong asymetric encryption as you'll ever need.
What you do is you send a challenge (random bytes) from the car to the token. It encrypts (read: signs) the challenge with the private key. Now the encrypted challenge can only be decrypted by the public key. The car does this and if it finds the challenge it knows that the token has the secret private key of the public/private key pair.
These chips can keep the private key pretty safe, so safe that it is really, really hard to get it ever out of the chip, even in a big lab. And with USB it is pretty easy to put some MB's or GB's next to it.
All this said, such a key would be easy to loose (forget you put it in a computer somewhere), and USB has not such a strong connector (even if better than most computer connectors). I hope they used one that was designed from scratch. It's not so much the security that I worry about.
Yeah, I've already started to write all 16 byte long numbers on my harddrive. The problem is that I'm a few bits short, some 309485009821345068724781056 of them. Oh, yeah, that's TERRA bits. You could divide by 8 to get bytes back, but I wonder how much good it would do you. Oh, and I forgot to remove your.008 Tb drive from it as well.
BT is highly popular, especially in Europe where most carkits, headphones and data transfer is done through BT. And BT is currently trying to synchronize with ultra high frequency specs (they get the application protocol, they get higher speeds). So BT probably takes 1/2 versions to get on par.
Re:Anybody can get code signed if they send cash
on
Do You Code Sign?
·
· Score: 1
Verisigns certificates are normally distributed by other means, for instance with your favourite web browser or operating system (or both). Furthermore, how do I know I can trust you or your site? With Verisign, users do have to provide some information and/or money (how much depend on the level of the certificate).
If they do something bad with their key, Verisign will put their certificate up on their Certificate Revocation List. And last but not least, where do you store your private key? I know Verisign will store their keys pretty safely. I bet they keep a watchfull eye on their webservers too. Their servers are much less likely to break than avarage.
I do not think that (P)GP(G) fits the bill that well for code-signing. Especially the revocation part seems to be missing. IF you do code signing yourself, use X509v3 certificates and make sure to keep your root keys safe, and publish revocation lists. You can use OpenCA or any other open source CA to keep track of your certificates and keys.
Note: I myself would not choose Verisign for code signing...
I see this book mostly as an opinion piece, as well as a good starting point on how to think about security. I must say I like his other books much more than this one.
The small part about code signing is just that, a not so well thought out part of his book with little around it to back it up. It mentions ActiveX especially, which probably means that it is taking code signing to mean "this package has safe code inside it, which other (untrusted) applications may run. I agree wholeheartely that this is little reason to trust some software package *alone*. This can be mitigated if said package runs in a sandbox itself, or has been proven to not contain buffer overflows, or requires user input to install or run. You get my drift.
But if code signing is used to show that an install package is from someone, and it is signed with its key, then code signing *can* provide some serious security benefits. Saying no to that means that putting digital signatures have no merit. This is however a very different use of code signing than the one Bruce seems to target.
This is not a good reason. Since *both* sandboxing and code signing can be used, you can have a safer system by not excluding one or the other because the other one is better.
That's like saying you don't want cream on your cake since it already has chocolate on it.
Re:"Always trust code from Microsoft"
on
Do You Code Sign?
·
· Score: 4, Informative
You mean like under windows, view a certificate, go to details tab, click edit properties, disable all purposes of this certificate? Something like that?
In firefox you will have to remove 3 ticks instead of one button, but those ticks are way easier to find. Not that anyone knows, but it is possible.
Re:"Always trust code from Microsoft"
on
Do You Code Sign?
·
· Score: 4, Insightful
You are trusing Microsoft code that folks other that Microsoft give you to run.
I know this is true, and bugs have been found in libraries. What was even more wrong is that the same key was used for multiple libraries, making it hard for Microsoft to put the key out of its misery (put it in a Certificate Revocation List.
This is an example where the technique is not so much wrong, but the system in which the technique is used is wrong (one of the spearpoints of Bruce). I do not want to give any web-site the ability to upload and install code on my computer, even if it is signed by someone I trust.
In principle, the idea that MS signs code for automatic updates of their own code is great, it takes out the man in the middle attack (taking over the update site, attack on proxies etc). Leave the code signing be, but leave the snags out.
Mod parent down! Serial ports normally operate on 112 bits/sec *and* Bluetooth v2 can transfer data at 3 Mb/sec. That's at least 2 of 3 that are wrong. And come to think at it, 1Mb/sec for Bluetooth v1, shouldn't that be 721 Kbit/sec or something like that? For gods sake slashdot, anyone awake?
This is *not* about opening their protocol. This is opening up their API so you can use a library (.dll probably) of theirs to integrate into your application. And even then it is more about seeing who is online than anything else. Which is unfortunate, since they seem to have gained a pretty big market.
Obviously, the AC that wrote the article before your article is also mistaken. If Skype keeps playing their game, they *won't* open up their protocol but sell it (to hardware manufacturers for instance).
We may have to write our own protocol. Since the techniques are pretty well known (UDP NAT traversal, AES encryption - probably stream based, and some support for codecs), nothing new there. It's their implementation and the way they've set up the network which makes Skype interesting.
And I agree with other posters, after reading a bit into SIP - forget it, way to complicated (way to configurable). You need a *simple* protocol that *works* if you want to get it widely adopted.
There is no GNU in Stallman, but there is quite a lot of EGO in Stallman. Furthermore, there is this story about "Muntplein" in Amsterdam. The registrates choose to call it differently - forgot the name. People just kept calling in "Muntplein". So even if it would be reasonable to call it GNU, it's called differently and I cannot see broad movement to call it GNU either.
Java's implementations (or actually, more the standards and the API) are controlled by Sun for a reason. If they were not controlled, they would fork too much, and the easy Java API would be lost. Since that same API is now pretty much established, it would be very welcome to open the whole thing up indeed. Java has already said they won't completely open it up unfortunately (I heard first hand at NLJUG Spring Conference).
As for compatibility. Java's API has been build up from the ground to do away with cross platform issues like path-names and GUI's. Take a look at the java.io.File class and the Swing (or SWT) API for examples. Obviously, the recompile problem is no issue, as is the use of incompatible (read Windows) API's. And with JNI you can build one standard Java class to talk to a Windows/Linux library in a standardised way. It's pretty easy to integrate into a COM or CORBA structure as well.
JSP's didn't suck to much, if they would have been well used. Nowadays you have many (maybe too many) Java Enterprise frameworks to choose from. These are highly popular, few people would use servlets/JSP's directly by now.
And a great Mono, Java and Python environment on a BSD based distro? I'm all for it!
First off, saying to rely on Mono is saying you'll have to develop for Java Classpath instead of Java itself. It is simply not the same thing. Java does not run on any platform but at least it runs on [insert endless list here].
Yes, you can independently create your own JVM.
As for the speed, especially with 1.5 this is pretty much a non-issue. Maybe memory still is, but hey, both systems are pretty much the same idea and use loads of memory. Maybe.NET is a bit more tweaked towards Windows though.
As for the speed of Eclipse, it is pretty sufficient for any developer, and it has much better capabilities (especially parser-wise). You'll have to use it to know what I am talking about (e.g. try the "mark occurences" in the config, and point to the return value of a method, all exit points light up immediately).
Exactly. As long as I can remember (and I remember pretty long) Java has run Applets in a Sandbox. This means that at least from 1.1 they had this sandbox (I'll have to look up my Java Core book to look if 1.0 had any). Also remember that Java has been designed with security in mind. That's why all arrays are bounds checked. So basically this claim is *utter* BS. Maybe the student in question was not around when Java hit the ground?
You are trying to be funny, but I'll bite..NET and Java are clearly a much cleaner subset of C++, with many runtime features. Both are designed to do away with many legacy programming features (like pointer arithmetic). These features will only take your eye off your original target (for a small speed advantage, granted).
These languages are less error prone and easier to debug. Therefore, they are the tool of choice for someone to create a program within a certain timeframe, a program which sources that can be read and changed for years to come (if well documented).
And yes, they use OO. Things like streams and those nice GUI's wouldn't be possible without it. Maybe namespaces are even more important though.
Well, the anandtech article is somewhat more readable for someone that is not directly planning to implement applications for the cell processor. It does a good job in explaining the "what's special" for the Cell microprocessor. And what we can expect to be incorperated in the PC arena in the next 20 years to come.
Or do you rather read microcode, assembly code or C/C++ language extension stuff?
Current operating systems do not really see the difference between cores and fake cores like hyperthreading. Distributing threads between cores and fake cores would be a rather tricky business. Rather just remove the hyperthreading stuff, which isn't likely to add too much performance benefits anyway, especially with these new processors.
Maybe there is not a huge overlap in their roles, but the fact remaines that I know a lot of admins that are playing games at home. And yes, that are the people that buy SLI gaming rigs, because they think it's cool to have, and they've got the money to actually buy it. Working geeks like me have all the good stuff:)
Great. Now about that reliable part in the thumbprint (fingerprint ?) scanning... Fingerprint scanning *can* be rather secure. By letting qualified personel watch persons while they perform the biometric verification. Artificial fingerprints are just too easy to make (and to get off glass, like for instance, the touch screen of a PDA).
I would myself rather opt for a PIN or similar scheme (e.g. put pictures in a specific order) to access the device. These kind of devices tend to get used pretty much, so the chance of somebody forgetting their password is minimal.
The mouse over feature does not seem to work on my computer. Before uninstalling, disable it using the options of the extension, and see if you like the effect.
I once had to go and display some computers for the employees for a garbage recycling company. Very nice and unexpectedly sophisticated people by the way.
Unfortunately, chance threw one of the dumbest my way. He asked where if he could create copies using the provided scanner. I had to explain (slowly, and multiple times) that you could do that using the computer and - of course - a printer.
He then went on asking where the (blank) paper had to go in, pointing to the scanner of course.
His wife was obviously quite a lot smarter, since we managed to share a moment of utter desperation.
Slashdot Mirror
Well, they needed to get to the chip first, then they would have a pretty good microscope (not your default kind of thingy) and they their attack might work. But nowadays most of the keys are stored encrypted with another (symetric) key that is not stored in main memory. Other kinds of memory are much harder to read. Note that this article has been published in 2002 and still smart card IC's get a CC AEL4+ rating. Not to say that there are no problems - attacking a chip with this attack has a much higher success rate than attacking an RSA key with any length over 512 bits. But this attack would at least be rather much for a car thief, even one that has a big criminal network behind it.
There are many USB tokens on the market. Probably a few of them will handle 2048 bit RSA keys. This is as strong asymetric encryption as you'll ever need.
What you do is you send a challenge (random bytes) from the car to the token. It encrypts (read: signs) the challenge with the private key. Now the encrypted challenge can only be decrypted by the public key. The car does this and if it finds the challenge it knows that the token has the secret private key of the public/private key pair.
These chips can keep the private key pretty safe, so safe that it is really, really hard to get it ever out of the chip, even in a big lab. And with USB it is pretty easy to put some MB's or GB's next to it.
All this said, such a key would be easy to loose (forget you put it in a computer somewhere), and USB has not such a strong connector (even if better than most computer connectors). I hope they used one that was designed from scratch. It's not so much the security that I worry about.
Yeah, I've already started to write all 16 byte long numbers on my harddrive. The problem is that I'm a few bits short, some 309485009821345068724781056 of them. Oh, yeah, that's TERRA bits. You could divide by 8 to get bytes back, but I wonder how much good it would do you. Oh, and I forgot to remove your .008 Tb drive from it as well.
BT is highly popular, especially in Europe where most carkits, headphones and data transfer is done through BT. And BT is currently trying to synchronize with ultra high frequency specs (they get the application protocol, they get higher speeds). So BT probably takes 1/2 versions to get on par.
Verisigns certificates are normally distributed by other means, for instance with your favourite web browser or operating system (or both). Furthermore, how do I know I can trust you or your site? With Verisign, users do have to provide some information and/or money (how much depend on the level of the certificate).
If they do something bad with their key, Verisign will put their certificate up on their Certificate Revocation List. And last but not least, where do you store your private key? I know Verisign will store their keys pretty safely. I bet they keep a watchfull eye on their webservers too. Their servers are much less likely to break than avarage.
I do not think that (P)GP(G) fits the bill that well for code-signing. Especially the revocation part seems to be missing. IF you do code signing yourself, use X509v3 certificates and make sure to keep your root keys safe, and publish revocation lists. You can use OpenCA or any other open source CA to keep track of your certificates and keys.
Note: I myself would not choose Verisign for code signing...
I see this book mostly as an opinion piece, as well as a good starting point on how to think about security. I must say I like his other books much more than this one.
The small part about code signing is just that, a not so well thought out part of his book with little around it to back it up. It mentions ActiveX especially, which probably means that it is taking code signing to mean "this package has safe code inside it, which other (untrusted) applications may run. I agree wholeheartely that this is little reason to trust some software package *alone*. This can be mitigated if said package runs in a sandbox itself, or has been proven to not contain buffer overflows, or requires user input to install or run. You get my drift.
But if code signing is used to show that an install package is from someone, and it is signed with its key, then code signing *can* provide some serious security benefits. Saying no to that means that putting digital signatures have no merit. This is however a very different use of code signing than the one Bruce seems to target.
This is not a good reason. Since *both* sandboxing and code signing can be used, you can have a safer system by not excluding one or the other because the other one is better.
That's like saying you don't want cream on your cake since it already has chocolate on it.
You mean like under windows, view a certificate, go to details tab, click edit properties, disable all purposes of this certificate? Something like that?
In firefox you will have to remove 3 ticks instead of one button, but those ticks are way easier to find. Not that anyone knows, but it is possible.
You are trusing Microsoft code that folks other that Microsoft give you to run.
I know this is true, and bugs have been found in libraries. What was even more wrong is that the same key was used for multiple libraries, making it hard for Microsoft to put the key out of its misery (put it in a Certificate Revocation List.
This is an example where the technique is not so much wrong, but the system in which the technique is used is wrong (one of the spearpoints of Bruce). I do not want to give any web-site the ability to upload and install code on my computer, even if it is signed by someone I trust.
In principle, the idea that MS signs code for automatic updates of their own code is great, it takes out the man in the middle attack (taking over the update site, attack on proxies etc). Leave the code signing be, but leave the snags out.
Mod parent down! Serial ports normally operate on 112 bits/sec *and* Bluetooth v2 can transfer data at 3 Mb/sec. That's at least 2 of 3 that are wrong. And come to think at it, 1Mb/sec for Bluetooth v1, shouldn't that be 721 Kbit/sec or something like that? For gods sake slashdot, anyone awake?
This is *not* about opening their protocol. This is opening up their API so you can use a library (.dll probably) of theirs to integrate into your application. And even then it is more about seeing who is online than anything else. Which is unfortunate, since they seem to have gained a pretty big market.
Obviously, the AC that wrote the article before your article is also mistaken. If Skype keeps playing their game, they *won't* open up their protocol but sell it (to hardware manufacturers for instance).
We may have to write our own protocol. Since the techniques are pretty well known (UDP NAT traversal, AES encryption - probably stream based, and some support for codecs), nothing new there. It's their implementation and the way they've set up the network which makes Skype interesting.
And I agree with other posters, after reading a bit into SIP - forget it, way to complicated (way to configurable). You need a *simple* protocol that *works* if you want to get it widely adopted.
There is no GNU in Stallman, but there is quite a lot of EGO in Stallman. Furthermore, there is this story about "Muntplein" in Amsterdam. The registrates choose to call it differently - forgot the name. People just kept calling in "Muntplein". So even if it would be reasonable to call it GNU, it's called differently and I cannot see broad movement to call it GNU either.
Anyway, what's in a name...
Java's implementations (or actually, more the standards and the API) are controlled by Sun for a reason. If they were not controlled, they would fork too much, and the easy Java API would be lost. Since that same API is now pretty much established, it would be very welcome to open the whole thing up indeed. Java has already said they won't completely open it up unfortunately (I heard first hand at NLJUG Spring Conference).
As for compatibility. Java's API has been build up from the ground to do away with cross platform issues like path-names and GUI's. Take a look at the java.io.File class and the Swing (or SWT) API for examples. Obviously, the recompile problem is no issue, as is the use of incompatible (read Windows) API's. And with JNI you can build one standard Java class to talk to a Windows/Linux library in a standardised way. It's pretty easy to integrate into a COM or CORBA structure as well.
JSP's didn't suck to much, if they would have been well used. Nowadays you have many (maybe too many) Java Enterprise frameworks to choose from. These are highly popular, few people would use servlets/JSP's directly by now.
And a great Mono, Java and Python environment on a BSD based distro? I'm all for it!
First off, saying to rely on Mono is saying you'll have to develop for Java Classpath instead of Java itself. It is simply not the same thing. Java does not run on any platform but at least it runs on [insert endless list here].
.NET is a bit more tweaked towards Windows though.
Yes, you can independently create your own JVM.
As for the speed, especially with 1.5 this is pretty much a non-issue. Maybe memory still is, but hey, both systems are pretty much the same idea and use loads of memory. Maybe
As for the speed of Eclipse, it is pretty sufficient for any developer, and it has much better capabilities (especially parser-wise). You'll have to use it to know what I am talking about (e.g. try the "mark occurences" in the config, and point to the return value of a method, all exit points light up immediately).
Exactly. As long as I can remember (and I remember pretty long) Java has run Applets in a Sandbox. This means that at least from 1.1 they had this sandbox (I'll have to look up my Java Core book to look if 1.0 had any). Also remember that Java has been designed with security in mind. That's why all arrays are bounds checked. So basically this claim is *utter* BS. Maybe the student in question was not around when Java hit the ground?
You are trying to be funny, but I'll bite. .NET and Java are clearly a much cleaner subset of C++, with many runtime features. Both are designed to do away with many legacy programming features (like pointer arithmetic). These features will only take your eye off your original target (for a small speed advantage, granted).
These languages are less error prone and easier to debug. Therefore, they are the tool of choice for someone to create a program within a certain timeframe, a program which sources that can be read and changed for years to come (if well documented).
And yes, they use OO. Things like streams and those nice GUI's wouldn't be possible without it. Maybe namespaces are even more important though.
Well, the anandtech article is somewhat more readable for someone that is not directly planning to implement applications for the cell processor. It does a good job in explaining the "what's special" for the Cell microprocessor. And what we can expect to be incorperated in the PC arena in the next 20 years to come.
Or do you rather read microcode, assembly code or C/C++ language extension stuff?
Yeah, it's time that we impose limits on traveling for our employees! (If you don't like it you can go work somewhere else!)
They would win the contest and loose the marketing battle. Itanium is dead in the water and Intel knows this.
I've quit reading hexus & tomshardware because of the inline commercial stuff. I would stay with the Inq and anandtech instead. Be warned.
Current operating systems do not really see the difference between cores and fake cores like hyperthreading. Distributing threads between cores and fake cores would be a rather tricky business. Rather just remove the hyperthreading stuff, which isn't likely to add too much performance benefits anyway, especially with these new processors.
Maybe there is not a huge overlap in their roles, but the fact remaines that I know a lot of admins that are playing games at home. And yes, that are the people that buy SLI gaming rigs, because they think it's cool to have, and they've got the money to actually buy it. Working geeks like me have all the good stuff :)
Great. Now about that reliable part in the thumbprint (fingerprint ?) scanning... Fingerprint scanning *can* be rather secure. By letting qualified personel watch persons while they perform the biometric verification. Artificial fingerprints are just too easy to make (and to get off glass, like for instance, the touch screen of a PDA).
I would myself rather opt for a PIN or similar scheme (e.g. put pictures in a specific order) to access the device. These kind of devices tend to get used pretty much, so the chance of somebody forgetting their password is minimal.
The mouse over feature does not seem to work on my computer. Before uninstalling, disable it using the options of the extension, and see if you like the effect.
I once had to go and display some computers for the employees for a garbage recycling company. Very nice and unexpectedly sophisticated people by the way.
Unfortunately, chance threw one of the dumbest my way. He asked where if he could create copies using the provided scanner. I had to explain (slowly, and multiple times) that you could do that using the computer and - of course - a printer.
He then went on asking where the (blank) paper had to go in, pointing to the scanner of course.
His wife was obviously quite a lot smarter, since we managed to share a moment of utter desperation.