Yes, GPS has everything to do with triangulation. Car proximity detection does not, and while it could use triangulation as a method of determining proximity, that would not prevent relay attacks in itself.
You cannot triangulate to the key when the key is out of contact with the vehicle. When the relay comes into contact with the vehicle, there is no way to determine it is not the key without simply relying on very precise timing in order to rule out a signal that has been relayed too far (say 20m vs 3m, which is on the order of 50ns). This has nothing to do with triangulation, and does not relate to current GPS technologies (which are spoofable, by the way).
Building a pocket size low power device that can reliably respond within an error margin of the tens of nano seconds regardless of remaining battery power seems difficult to me, but it is not my area of expertise so maybe it is trivial. But this still has nothing to do with triangulation.
Your solution won't work. All you will be doing is triangulating the position of the relay, and not the key itself. The relay will be within the proximity of the vehicle, and so the car will unlock.
Now, maybe if both the key and the car had their own GPS receivers and transmitted their actual location as part of the communication then the car could verify where the key actually thought it was, but this would fail completely in underground parking lots etc.
The only other solution is to base the unlock on very precise timing, but the tolerance has to be under about 50 nano seconds to be effective, which is probably too difficult to achieve reliably.
No, the car sends the key a challenge, such as a timestamp or a random number. The key has to respond, but modifies the response (e.g. XOR) based on the challenge. You could replay it, but the challenge is different each time.
Relay and replay are two different things.
I am sure if you ponder it long enough you will realize why you are incorrect.
The challenge will be correct because the key itself is performing it.
All the attack is doing is effectively extending the range of the communication between the key and the car. Since the car unlocks anytime it can communicate with the key, this effectively breaks the security.
There is no practical way to prevent the attack described in the article through key strategies or encryption. The solution you propose would not work because the entire handshake can be relayed between the key and the car. The man in the middle in this case does not care to decrypt or modify the data, they are acting as no more than a router on the Internet would be when it passes your SSL packets.
One possible solution that doesn't change the fundamental passive monitoring mechanism is to rely on very fine grained timing of the response (say the difference between how long it takes the speed of light to travel 2 meters vs 50 meters). I am not sure if such a system could be built reliably for a low cost.
PKI won't help. The problem is that the attacker does not care about decrypting the data, they only need to relay the data in order for the car to unlock.
All an attacker needs to do for these systems is extend the range (via repeating the signal) in order to compromise the security. No amount of encryption will help in this situation.
It's hard to think how Microsoft can make the next Windows better from Windows 7.
I'd like to see more support for per application permissions. Each application should be able to be restricted in terms of where it can read / write, what system properties it can modify, and what network resources it can use. This would need to be far more granular than simply allowing a program administrative permission or not.
The above should all be implemented easily for the user, with the program requesting specific rights as needed (or during installation).
I have not checked how d0z.me invokes its targets since I do not plan on loading that site from work, but if it is via an IFrame, then there will be a referrer, at least in all of the web browsers that I am familiar with (excluding browsers that allow you to disable the referrer).
The referrer should still be present in the request though, which would seem to make filtering trivial (if not for the site itself, for the upstream providers). A DDOS like this would then work well in the short term, but fall apart completely once the site operators were in touch with the upstream providers.
Of course, I could be wrong about the referrer being present in requests made from Javascript, but I assume it should be there.
Apparently even Microsoft realized that having users fumble with a key wheel or lookup a word in the manual every time they started their computer or ran Office would be a user experience disaster.
Not being able to prevent piracy does not equate to encouraging it, regardless of whether they benefited from it or not.
You are correct, jurors are forbidden from doing their own investigation. I did not mean to imply that they were allowed to, my point was that there is a strong incentive for them to do so, regardless of the rules.
When making an important decision, it is natural to desire as much information as possible in order to make the best possible decision. If jurors question what they have heard in the courtroom, or have doubts about particular aspects, then they will have an incentive to research the issue on their own.
I would be intrigued to learn if any studies had been done about such cases that show whether juries who broke them rules in this fashion arrive at "better" or worse verdicts (where it is possible to determine what a "better" verdict is).
This is going to be a very tough issue for the courts to resolve since there will always be a strong desire for some jurors to do their own investigations while they are grappling with a tough verdict. I think that many of us would be very inclined to do our own research if we were jurors if just to determine which set of expert witnesses (defense or prosecution) is more correct.
It would be very hard to not lookup details, precedents, and opinion on cases which you are weighing and ultimately responsible for the future life of an individual. I am actually surprised that this type of issue does not happen more often (and, in fact, it probably does happen a lot more often than the numbers reported in the article, as the article itself hints at).
Oracle is very likely to always continue to release a free JDK / JVM. They have already stated this (along with mentioning that they will also continue to release their for pay JVM).
While Oracle may seem heavy handed with Java at the moment, it is worth noting that Oracle needs Java to continue to succeed. How many ASP / C# shops do you know that use an Oracle backend? Probably a lot less than the ones that use MSSQL. Oracle cannot afford for Java to be completely eclipsed by MS offerings, so they will not kill Java, rather they will push it to maintain pace with any other server side development environment.
On the other hand, they will extract money from big players where they think they can get it, which is why they go after Google and mobile implementations. The mobile market is not using any Oracle products, so it is not profitable to them unless they make money from it via licensing.
I've been using Chrome for ages, but it seems to me like it's already way faster than it would have to be. I use a very dated machine and cannot usually saee Chrome being much faster than Firefox 3.5.12.
Improving Javascript speed allows for more complex and feature rich Javascript applications to be developed. The whole impetus for Google to develop Chrome can likely be traced back to their desire to have a fast and stable platform on which they can deliver their web applications.
If we consider Google's Javascript based word processor and spreadsheet applications then it is clear that the speed of the underlying Javascript engine is a key component in the applications' usability. Pushing the pace of Javascript development directly allows Google to expand the functionality of its web applications and compete more evenly with non-web based applications.
The null checking and so called Elvis operators mentioned in tip #1 were considered for JDK 1.7, but ultimately ruled out. They do not exist in JDK1.6, and unless something changes, they will not exist in JDK 1.7 or 1.8.
It is a little bit ironic that the author cannot be bothered to get the details right in a tip about getting the details right...
It is possible that they did use CA's JDBC driver and that doing so is precisely the problem. CA may perhaps be claiming that the JDBC driver (or ODBC driver) for their database was used contrary to the licensing agreement.
I hope that this is not the case, for if it is, and if they prevail, then the ramifications are considerable.
What's far more likely is that Activision treated their devs like crap (surprise surprise) and for most of them, having the heads of IW fired was the final straw.
This is ironic because Activision (the original Activision) was founded expressly to treat developers better. To quote from Wikipedia:
"Before the formation of Activision, software for video game consoles were published exclusively by makers of the systems for which the games were designed. For example, Atari was the only publisher of games for the Atari 2600. This was particularly galling to the developers of the games, as they received no financial rewards for games that sold well, and did not receive credit for their games. This caused several programmers to resign from their jobs. Activision became the first third-party game publisher for game consoles."
Companies usually only resort to patent warfare when they are otherwise doing poorly. Additionally, in some sense, Nokia is duty bound to pursue their patents against Apple in order to maximize shareholder value.
I agree, there is seemingly a large amount of stupidity involved in the situation.
The principal not only could have, but SHOULD have interviewed the student to ascertain the risk. However, say the principal is sitting there with the student with a device with wires sticking out of it all over the place. The principal doesn't know enough about electronics to to be sure whether it is a safe device, or is indeed a bomb. Additionally, the principal doesn't trust the student since if it is a bomb the student probably wouldn't admit to it.
So, given this situation, the principal, as a self optimizing and very self interested individual, decides that there is no advantage or reason for them to take the risk of trusting the student. They error way over on the side of caution since there is no compelling reason for them not to.
Until there are actual ramifications for raising a false alarm, issues like this are not only likely to continue, but inevitable. If the school or principal was billed for the cost of a false alarm (or just a token percentage of it) then I would be will to bet that you would see the cases of false alarms drop dramatically.
It isn't necessarily ineptitude that causes school officials to make decisions like this. The basic reasoning boils down to the fact that the school officials will take little if any flack for over reacting in the name of safety, but they will lose their jobs and be raked through the mud if they fail to react to an "obvious" threat.
Part of the problem is that no one ever gets rewarded for the issues they chose to ignore. So there is no benefit to the principal to ignore what they think is a possible threat even if the probability of it being a threat is vanishingly small.
The end result is that school officials with a high self interest will put their self interest in front of everyone else (the authorities who are wasting their time, the students out of class, the student directly involved, the parents who have to come pick up all the students early, etc), since they are more worried about the ramifications to themselves than the trouble they may cause for others.
Slashdot Mirror
Yes, GPS has everything to do with triangulation. Car proximity detection does not, and while it could use triangulation as a method of determining proximity, that would not prevent relay attacks in itself.
GPS spoofing is mentioned here, for one:
http://www.schneier.com/blog/archives/2008/09/gps_spoofing.html
You cannot triangulate to the key when the key is out of contact with the vehicle. When the relay comes into contact with the vehicle, there is no way to determine it is not the key without simply relying on very precise timing in order to rule out a signal that has been relayed too far (say 20m vs 3m, which is on the order of 50ns). This has nothing to do with triangulation, and does not relate to current GPS technologies (which are spoofable, by the way).
Building a pocket size low power device that can reliably respond within an error margin of the tens of nano seconds regardless of remaining battery power seems difficult to me, but it is not my area of expertise so maybe it is trivial. But this still has nothing to do with triangulation.
Your solution won't work. All you will be doing is triangulating the position of the relay, and not the key itself. The relay will be within the proximity of the vehicle, and so the car will unlock.
Now, maybe if both the key and the car had their own GPS receivers and transmitted their actual location as part of the communication then the car could verify where the key actually thought it was, but this would fail completely in underground parking lots etc.
The only other solution is to base the unlock on very precise timing, but the tolerance has to be under about 50 nano seconds to be effective, which is probably too difficult to achieve reliably.
No, the car sends the key a challenge, such as a timestamp or a random number. The key has to respond, but modifies the response (e.g. XOR) based on the challenge. You could replay it, but the challenge is different each time.
Relay and replay are two different things.
I am sure if you ponder it long enough you will realize why you are incorrect.
The challenge will be correct because the key itself is performing it.
All the attack is doing is effectively extending the range of the communication between the key and the car. Since the car unlocks anytime it can communicate with the key, this effectively breaks the security.
I said 'relay', not 'replay'.
There is no practical way to prevent the attack described in the article through key strategies or encryption. The solution you propose would not work because the entire handshake can be relayed between the key and the car. The man in the middle in this case does not care to decrypt or modify the data, they are acting as no more than a router on the Internet would be when it passes your SSL packets.
One possible solution that doesn't change the fundamental passive monitoring mechanism is to rely on very fine grained timing of the response (say the difference between how long it takes the speed of light to travel 2 meters vs 50 meters). I am not sure if such a system could be built reliably for a low cost.
PKI won't help. The problem is that the attacker does not care about decrypting the data, they only need to relay the data in order for the car to unlock.
All an attacker needs to do for these systems is extend the range (via repeating the signal) in order to compromise the security. No amount of encryption will help in this situation.
// TODO remove this
sleep(30);
I'm still having a hard time understanding what technologies exist in 7 that don't in XP AND are something I ( or a business would need )
Have you seen the transparent windows?
It's hard to think how Microsoft can make the next Windows better from Windows 7.
I'd like to see more support for per application permissions. Each application should be able to be restricted in terms of where it can read / write, what system properties it can modify, and what network resources it can use. This would need to be far more granular than simply allowing a program administrative permission or not.
The above should all be implemented easily for the user, with the program requesting specific rights as needed (or during installation).
One can dream...
Scratch that, IFrames don't send the framing page as a referrer, at least in the tests I just tried.
I have not checked how d0z.me invokes its targets since I do not plan on loading that site from work, but if it is via an IFrame, then there will be a referrer, at least in all of the web browsers that I am familiar with (excluding browsers that allow you to disable the referrer).
The referrer should still be present in the request though, which would seem to make filtering trivial (if not for the site itself, for the upstream providers). A DDOS like this would then work well in the short term, but fall apart completely once the site operators were in touch with the upstream providers.
Of course, I could be wrong about the referrer being present in requests made from Javascript, but I assume it should be there.
Apparently even Microsoft realized that having users fumble with a key wheel or lookup a word in the manual every time they started their computer or ran Office would be a user experience disaster.
Not being able to prevent piracy does not equate to encouraging it, regardless of whether they benefited from it or not.
You are correct, jurors are forbidden from doing their own investigation. I did not mean to imply that they were allowed to, my point was that there is a strong incentive for them to do so, regardless of the rules.
When making an important decision, it is natural to desire as much information as possible in order to make the best possible decision. If jurors question what they have heard in the courtroom, or have doubts about particular aspects, then they will have an incentive to research the issue on their own.
I would be intrigued to learn if any studies had been done about such cases that show whether juries who broke them rules in this fashion arrive at "better" or worse verdicts (where it is possible to determine what a "better" verdict is).
This is going to be a very tough issue for the courts to resolve since there will always be a strong desire for some jurors to do their own investigations while they are grappling with a tough verdict. I think that many of us would be very inclined to do our own research if we were jurors if just to determine which set of expert witnesses (defense or prosecution) is more correct.
It would be very hard to not lookup details, precedents, and opinion on cases which you are weighing and ultimately responsible for the future life of an individual. I am actually surprised that this type of issue does not happen more often (and, in fact, it probably does happen a lot more often than the numbers reported in the article, as the article itself hints at).
Oracle is very likely to always continue to release a free JDK / JVM. They have already stated this (along with mentioning that they will also continue to release their for pay JVM).
While Oracle may seem heavy handed with Java at the moment, it is worth noting that Oracle needs Java to continue to succeed. How many ASP / C# shops do you know that use an Oracle backend? Probably a lot less than the ones that use MSSQL. Oracle cannot afford for Java to be completely eclipsed by MS offerings, so they will not kill Java, rather they will push it to maintain pace with any other server side development environment.
On the other hand, they will extract money from big players where they think they can get it, which is why they go after Google and mobile implementations. The mobile market is not using any Oracle products, so it is not profitable to them unless they make money from it via licensing.
I've been using Chrome for ages, but it seems to me like it's already way faster than it would have to be. I use a very dated machine and cannot usually saee Chrome being much faster than Firefox 3.5.12.
Improving Javascript speed allows for more complex and feature rich Javascript applications to be developed. The whole impetus for Google to develop Chrome can likely be traced back to their desire to have a fast and stable platform on which they can deliver their web applications.
If we consider Google's Javascript based word processor and spreadsheet applications then it is clear that the speed of the underlying Javascript engine is a key component in the applications' usability. Pushing the pace of Javascript development directly allows Google to expand the functionality of its web applications and compete more evenly with non-web based applications.
The null checking and so called Elvis operators mentioned in tip #1 were considered for JDK 1.7, but ultimately ruled out. They do not exist in JDK1.6, and unless something changes, they will not exist in JDK 1.7 or 1.8.
It is a little bit ironic that the author cannot be bothered to get the details right in a tip about getting the details right...
It is possible that they did use CA's JDBC driver and that doing so is precisely the problem. CA may perhaps be claiming that the JDBC driver (or ODBC driver) for their database was used contrary to the licensing agreement.
I hope that this is not the case, for if it is, and if they prevail, then the ramifications are considerable.
The particular article being referred to is: http://apple.slashdot.org/story/01/10/23/1816257/Apple-releases-iPod
The "Lame" comment was appended to the submission by Slashdot editor CmdrTaco, in what some would now consider a bit of a misjudgment.
What's far more likely is that Activision treated their devs like crap (surprise surprise) and for most of them, having the heads of IW fired was the final straw.
This is ironic because Activision (the original Activision) was founded expressly to treat developers better. To quote from Wikipedia:
"Before the formation of Activision, software for video game consoles were published exclusively by makers of the systems for which the games were designed. For example, Atari was the only publisher of games for the Atari 2600. This was particularly galling to the developers of the games, as they received no financial rewards for games that sold well, and did not receive credit for their games. This caused several programmers to resign from their jobs. Activision became the first third-party game publisher for game consoles."
Charging one entity more than another is not anti-competitive behavior.
For reference of what is actual anti-competitive behavior, see here: http://en.wikipedia.org/wiki/Anti-competitive_practices
Companies usually only resort to patent warfare when they are otherwise doing poorly. Additionally, in some sense, Nokia is duty bound to pursue their patents against Apple in order to maximize shareholder value.
I agree, there is seemingly a large amount of stupidity involved in the situation.
The principal not only could have, but SHOULD have interviewed the student to ascertain the risk. However, say the principal is sitting there with the student with a device with wires sticking out of it all over the place. The principal doesn't know enough about electronics to to be sure whether it is a safe device, or is indeed a bomb. Additionally, the principal doesn't trust the student since if it is a bomb the student probably wouldn't admit to it.
So, given this situation, the principal, as a self optimizing and very self interested individual, decides that there is no advantage or reason for them to take the risk of trusting the student. They error way over on the side of caution since there is no compelling reason for them not to.
Until there are actual ramifications for raising a false alarm, issues like this are not only likely to continue, but inevitable. If the school or principal was billed for the cost of a false alarm (or just a token percentage of it) then I would be will to bet that you would see the cases of false alarms drop dramatically.
It isn't necessarily ineptitude that causes school officials to make decisions like this. The basic reasoning boils down to the fact that the school officials will take little if any flack for over reacting in the name of safety, but they will lose their jobs and be raked through the mud if they fail to react to an "obvious" threat.
Part of the problem is that no one ever gets rewarded for the issues they chose to ignore. So there is no benefit to the principal to ignore what they think is a possible threat even if the probability of it being a threat is vanishingly small.
The end result is that school officials with a high self interest will put their self interest in front of everyone else (the authorities who are wasting their time, the students out of class, the student directly involved, the parents who have to come pick up all the students early, etc), since they are more worried about the ramifications to themselves than the trouble they may cause for others.