I agree with your basic conclusion: the heat one feels when using a cell phone or handheld transceiver is due to the fact that much of the energy being consumed isn't being converted into RF. It's hard to make a transmitter that converts more than 30-40% of the energy consumed into RF, and efficiencies as poor as 10% or so aren't unusual.
But I did want to make a gentle technical correction. Your message suggests that there's very little absorption in the 2M (144-148 MHz) band used by your HT; this is actually incorrect.
Heating from RF is can be quantified by the specific absorption rate (SAR) of the body being heated when exposed to RF. As the name suggests, it's the amount of RF that gets absorbed by tissue in the body (which results in heating). It's usually measured in watts per kilogram.
It actually takes LESS power at VHF frequencies (like 2 meters) to reach a given SAR than it does at UHF, microwave, or HF. It's a result of resonance effects as the wavelength approaches the size of the human body.
Take a look at the FCC's OET Bulletin 65, which specifies the power levels at which you have to undertake an RF safety review of your amateur station. These power levels are derived from the amount of energy at a given frequency required to achieve a specific SAR. Note that for VHF, just 50 watts is enough to trigger the requirement. At HF frequencies, the levels are often much higher (500 watts for the 40M band, for example). In the 13cm band (2.4 GHz), you need to be operating at 250 watts or above before the FCC feels you need to do a routine evaluation for RF safety.
Greg Lapin, N9GL, has written about this fairly extensively on the ARRL Web site if you (or anyone else) are interested in learning more.
Once again, I'm not challenging your conclusion that most of the heat from holding a phone or radio transmitter is simply waste heat. And I'm certainly not asserting that there's any danger in using a cell phone or HT. But I thought you might be interested to know that the body actually is heated MORE by a given power level in the VHF range than it is by the frequencies used by cell phones.
I really feel for all the folks who have to deal with this outage; it's no fun at all!
A client of mine had a number of servers in a Sterling, Virginia data center managed by Verio/NTT. It's a good data center and seems to be well-run.
Last September, the data center experienced two complete power failures in the span of three days. To their immense credit, data center management was straight with customers about what had happened. For those who might be interested, their statements about the problem appear here.
My point? Make sure you know how to bring your systems back up from a completely cold start, and that you find a way to test this periodically. While we work to ensure that this sort of situation occurs rarely, the fact remains that these sorts of failures DO occur, and they're not as uncommon as the sales and marketing folks would like you to believe.
In the security business, a lot of the danger from IT employees comes from a class of attack known as "abuse of authority." It's near-impossible to prevent through technical measures, since the people in question need the elevated privileges in order to do their jobs. A careful program of auditing can often detect these abuses after they've occurred, however.
I had a situation occur a few years ago in which I had to fire a trusted and valuable staff member for snooping through a senior manager's email. Another staff member actually detected this when he printed a copy of the email, and it came out of the printer in his home office even though he was on travel. This came to my attention very quickly, and we reviewed audit logs that we'd put in place earlier and found plenty of evidence of his snooping. It pained me to fire the guy--he was smart, ambitious, and held up really well under pressure. But in the end, I concluded that a slap on the wrist would just send the message to other team members that it was OK to cheat until caught for the first time. I suspect that it was the right move for him, too; our sudden, decisive response to his lapse in judgment doubtless made an impression.
So, some advice to IT managers: ensure that there's an audit trail for all privileged activity. You'll detect and stop abuse if it's going in, and will deter staffers from being tempted to misuse their rights.
The fine article is interesting, though it sure reads a bit like the sort of article mentioned in Paul Graham's excellent essay "The Submarine". The suit is back!
It's about time for the financial services industry to step up and take responsibility for designing a payment infrastructure that can accomodate the current threat environment. A sixteen-digit reuseable number can't provide adequate security, even when coupled with real-time billing address and CVV2 tests. Payments need to be authorized individually by the accountholders, and these authorizations need to be tied to a specific date, time, merchant, and amount (or in the case of recurring payments, a time span, number of payments, and maximum aggregate amount). In this scheme, leakage of an account number doesn't connote authorization for payment--and leakage of a payment authorization doesn't enable re-use by others.
It will be hugely difficult and very expensive to make this change, of course, as it involves replacing a great deal of infrastructure. But ultimately it will be required due to the simplicity of fraud using today's technology. It's gotten to the point where most of the difficulty and expense isn't the technology for payment authorization; it's instead the cost associated with the changeover itself and with retraining consumers and merchants.
So, from where I sit, it looks like the costs of fraud being absorbed by the financial services industry (and, of course, being passed on to consumers in the form of higher fees) aren't being offset by a decrease in the eventual cost of making the system secure. It's time for the financial services community to take responsibility, then: accept the fact that it will be difficult and expensive to make the change, but also accept its necessity and inevitability.
My suspicion is that the CPU is a whole lot faster at performing an XOR on a relatively large block of memory than it is at doing a correspondingly larger number of XOR iterations on a few bytes. In particular, the MMX instruction set extensions were designed to handle logical operators on large blocks efficiently. By doing it a little at a time, you spend a correspondingly large amount of time handling your loop counter and associated comparisons.
So, you're saying that somehow your software RAID is calculating XOR bits and such without putting a serious hurt on your CPU and memory? Interesting.
I'm not the original poster to whom you're responding, but the answer to your question is actually kind of surprising (it was to me, in any case).
At any given point in time, your system is in one of three states:
partially idle (there's unused CPU and disk I/O capacity),
CPU-bound (the CPU is fully utilized but there's disk I/O bandwidth available), or
I/O bound (the CPU has spare cycles, but the disk can't provide data fast enough to put them to use).
I suppose that a heavily overloaded system could be both CPU and I/O bound, but it would require a mix of CPU- and disk-intensive processes that isn't usually seen in practice.
Let's ignore the partially idle case, in which there's ample disk and CPU to go around, as it doesn't really matter in this scenario whether the CPU or disk controller perform the XOR operations.
In the case of a CPU-bound process, you're going to incur the additional CPU overhead of the XOR operation. XOR is almost absurdly fast, particularly if the data is in the CPU's cache. I'm pretty sure that modern CPUs execute XOR on at least one byte per clock cycle. But let's say, for the sake of argument, that it takes three cycles per byte. On a CPU clocked at 3 GHz, you'd be able to perform XORs on one gigabyte of data per second if you ignore memory and cache issues. Given moderate memory bandwidth, you're also able to transfer over a gigabyte of data to or from the CPU per second. Given a more reasonable amount of data (say, one megabyte, to transfer), you'd be looking at a CPU impact of around one millisecond to perform the XOR. That's a 0.1% impact at most in a CPU-bound environment, and that's presuming you're doing a megabyte of disk I/O per second.
Now let's look at the I/O-bound case. Here, the CPU is sitting around waiting for the disk I/O to finish up. In this case, it clearly doesn't matter who's doing the XOR operations, since the CPU isn't fully utilized. PCI bus utilization is going to be increased by up to 100% (in the worst-case scenario involving drive mirroring; the worst-case RAID5 scenario is a 50% increase). A typical server's 66 MHz 64-bit PCI bus has a capacity of around 533 megabytes per second (PCI Express increases this dramatically, but let's stick with pessimistic examples for now). At the moment, a SCSI bus tops out at 320 megabytes per second, and those transfer rates are only achievable with at least four drives on the channel and an almost exclusively sequential I/O mix (the best-case numbers for a 15,000-RPM drive are about 100 megabytes/second). So there's generally bus bandwidth to spare.
You raise a number of other points in your note that are potentially issues (hot swappability, for example). But I've become convinced that the CPU/machine performance argument against software RAID really only made sense when CPUs/memory/bus bandwidth were much more constrained.
Your point regarding public-key crypto is particularly well-taken. Since the authentication we're talking about is between two parties (car and key) that have been introduced previously, a shared-secret form of authentication would work fine.
And I'm in complete agreement that an inexpensive and low-powered processor can perform cryptographic functions like DES/3DES, SHA-1, or MD5 very quickly.
You've also made an excellent point regarding when authentication actually occurs. The car definitely senses the key autonomously; exterior lights on the car illuminate when it's nearby. I'm not sure this first round of illumination depends on having the correct key, though, and I'm pretty sure a second round of communication takes place when the handle is touched. This obviously requires some additional experimentation!
Thanks again for your comments, even if you've violated a long-standing Slashdot tradition by supporting your assertions with actual facts!;-)
Thanks for the specifics. I haven't worked with smart cards in the last couple of years, so it's good to get some up-to-date information!
I concur that key generation time is basically irrelevant, since it's done so rarely (presumably only when the key is introduced to the vehicle).
But even a 417ms budget for authentication (car sends an "encrypt this random token with your private key and then send it back" challenge) is most likely too long. One of the operations I didn't mention involves unlocking the car. When you grab the door handle, you touch a contact point on the back. The car interrogates your key; if you have it (and it passes authentication), the car unlocks. In practice, this means you walk up to the car, grab the door handle, and pull. A couple of beeps is really the only way you know the car was locked in the first place. Fast as public-key crypto is on modern cards, 0.4 seconds is too long to wait for this operation to seem natural. It's probably too long to wait for the ignition keyswitch to react, too.
One thing that I should emphasize strongly: I have no idea whether there's any strong crypto at all going on between the key and the car when using the battery-powered transponder! It's entirely possible that the long-range transponder mode is doing something much less secure. For example, the car might be saying, "take this random token, encrypt it with a pre-shared symmetric key, and send it back." In this case, pretty well anything would have the processing horsepower to pull it off, and a battery would only serve to increase range, as you pointed out in your response to my original comment.
Sorry, I wasn't very clear! Thanks for catching my error.
I should have said that the car refuses to let you park and lock it while leaving the key behind. The semantics of this are fairly complex: the car won't lock if a door is open and the key is in the passenger compartment (i.e. you're getting out of the car and click the lock button). There's also a lock button on the outside of the car's door handle; that, too, won't work if the key is inside, regardless of whether the door is open or closed.
It's almost impossible to do this unknowingly; there's an error beeper that sounds whenever the car senses that the key is in the wrong place (in the passenger compartment/trunk when locking the car, or when removed from the passenger compartment while the engine is still running). In the latter case, the car can still be driven (though the beeper will drive you crazy). Once stopped, though, it won't restart.
The car can be locked from inside with the doors closed (this will arm the alarm if it's done while the car is parked and turned off). In fact, putting the transmission in gear will normally lock the car automatically.
You're absolutely right: smart cards with no batteries can indeed do these things. But they typically can't do these things very quickly. This is especially true of public-key operations like RSA; DES (and, therefore, 3DES) was designed to be computationally efficient.
There's a relationship between processing speed and power consumption. Having the battery allows the processor to run more quickly than is possible in a contactless smart card.
In addition, there's also a power and bandwidth issue: having more RF output power will generally allow you to send more data in a given unit of time.
This matters in an automotive environment; the driver expects to be able to turn the ignition switch and have the car immediately start. Waiting some number of seconds for a key exchange to occur, while more secure, isn't likely to be acceptable to the end user. Having more power available for the processor makes it possible to do something more sophisticated in the same amount of time.
It's completely possible, of course, that the battery only increases the range in this application. But, given a response time constraint, the availability of more current will give the designer of the system additional flexibility when choosing between cryptographic schemes.
One of the things the key transmits is a battery status, so you'd have to ignore a "low battery" warning message for a while in order to wind up with a completely dead battery.
Even then, you can start the car by putting the key into the ignition. In that case, a short-range unpowered transponder (presumably of the sort described in the article) is used to authenticate the key. You just lose the convenience of being able to leave the key in your pocket/briefcase/purse until you replace the battery.
Actually, the Lexus keys just use a reverse cut. The photo posted is of a blank (uncut) key. Here is a photo of a key that's been cut; note that it has a pattern that can be viewed/impressioned easily. It's still more secure, though, as it's an asymmetrical cut with pins on BOTH sides of the keyway.
Some of the newer Lexus keys do use RFID exclusively for starting the car. The key has a battery in it, and is designed to be queried from a significant distance (several feet), as it does NOT need to be in the ignition to operate. The car also refuses to lock if the key is in the passenger compartment, and the trunk won't close if the key is inside. There's a light on the key that illuminates when it transmits. Based on observation, it looks like the key won't respond unless it's queried directly, so capturing data from one of these keys would involve a small bit of additional complexity. I suspect that the presence of the battery allows much more robust encryption, as well.
I drive an LS430. The navigation system, phone, audio system, and air conditioning control system are driven by a system made by Denso. I can't say with certainty what operating system it's running, but it looks like an evolution of a design they've had going since at least 1998.
The Bluetooth interface is rather limited. You can use the hands-free capability after pairing it with your phone. You can transfer a phonebook using the OBEX profile. To my knowledge, none of the other Bluetooth profiles are supported--most notably the Object Push Protocol (OPP). In order to get OBEX phonebook transfers to work, you have to put the car phone system into a special mode; it won't just blindly accept transfers--even from paired devices. If this system is running Symbian and is really vulnerable, I wonder if it manifests itself only when attempting to transfer phonebook entries from an infected device.
The same navigation system is used in a number of cars beyond the Lexus LS430 and LX470. The SC430, GX430, and RX330 use the same Bluetooth system, as does Toyota's Land Cruiser and Prius.
I completely agree with you about "living on the edge;" that's the consumer's fault, not a card issuer's.
You're also absolutely correct that without a physical signature, a merchant doesn't have a guarantee of payment from the card issuer. But your point underscores even more strongly the need for a better system than we've got right now. Otherwise, the message is essentially, "all electronic commerce is a crapshoot; work face-to-face if you want to have any hope of getting paid."
I'd also argue that fraud isn't really just a loss for the merchant; those losses are baked into the cost of every product the merchant sells--just as is the case with shoplifting, inventory shrinkage, etc. Tighter controls will ultimately benefit everyone involved in the transaction.
While there's been plenty of talk about responsible protection of one's personal data (being careful about supplying information to an online site, for example), it sure seems like there are two areas of responsibility that are being overlooked.
First, it's about time for the financial services industry to step up and take responsibility for designing a payment infrastructure that can accomodate the current threat environment. A sixteen-digit reuseable number isn't the answer, even when coupled with real-time billing address and CVV2 tests. Payments need to be authorized individually by the accountholders, and these authorizations need to be tied to a specific date, time, merchant, and amount (or in the case of recurring payments, a time span, number of payments, and maximum aggregate amount). In this scheme, leakage of an account number doesn't connote authorization for payment--and leakage of a payment authorization doesn't enable re-use by others.
It will be hugely difficult and very expensive to make this change, of course, as it involves replacing a great deal of infrastructure. But ultimately it will be required due to the simplicity of fraud using today's technology. It's gotten to the point where most of the difficulty and expense isn't the technology for payment authorization; it's instead the cost associated with the changeover itself and with retraining consumers and merchants.
So, from where I sit, it looks like the costs of fraud being absorbed by the financial services industry (and, of course, being passed on to consumers in the form of higher fees) aren't being offset by a decrease in the eventual cost of making the system secure. It's time for the financial services community to take responsibility, then: accept the fact that it will be difficult and expensive to make the change, but also accept its necessity and inevitability.
Second, it's time for the users of Internet connections to take responsibility for the devices they connect. While I'm sympathetic to the fact that grandma probably isn't a PC administrator, and isn't aware that her machine was 0wn3d two years ago and has been a spam zombie ever since, I don't think we as an Internet-age society should simply absolve users of any responsibility for the health of their machines. One reasonable parallel is a burglar alarm. In the locality where I live, you're allowed one or two false alarms per year, then you start racking up fines. This makes sense to me: it's not good to penalize the innocent and ignorant unwittingly, but those that continue to consume resources (in this case, police time) are given an economic incentive to improve their infrastructure. It would have to be done carefully, but treating long-term spam zombies as civil infractions might provide the incentives necessary for users (and, of course, the vendors that serve them) to improve their security profile. Just as with the institutional changes in the financial services arena discussed above, this would be really difficult to do, particularly given the borderless nature of the Internet. But I'm not sure that difficulty is a good enough reason to avoid requiring computer owners take reasonable responsibility for their use.
I, too, am using the Aircard 5220 under Linux using Phil Karn's instructions.
Verizon's 1XEVDO service has been launched in a lot of markets now. It's comparable to DSL throughput (base data rate of 2.4 megabits/second with real throughput of 300-500 Kbit/s), though latency isn't comparable to a wired connection.
Where 1XEVDO service isn't available, though, the card *will* automatically fall back to using 1XRTT service, which is deployed basically everywhere. Data rates are much slower (144 Kbit/s base rate, with actual throughput of 35-40 Kbit/s). I don't if the previous poster has had problems with the EVDO-to-RTT fallback or simply hasn't had occasion to try it, but I've had no problems with it.
XM's data stream is encrypted. I have no inside knowledge of the matter other than the fact that I'm a paying subscriber to the service. That said, I imagine that what's sent down to your receiver every so often is the crypto keys required to decrypt the audio channels (I'd guess one key per channel or service tier, to allow for premium services, sports blackouts, etc.).
Since this audio decryption key is going to be the same for every radio, it's further encrypted against a unique key in the radio. Your radio receives a broadcast containing its serial number and an encrypted key. I wouldn't be surprised at all if there were actually multiple keys sent, along with validity periods (use this key until time X, then this key until time Y, etc.). Your radio then uses its unique key to decrypt the shared keys, and stores them away in its memory.
Providing multiple keys in advance makes things a lot easier when you can't guarantee that a particular receiver will be on to receive the key; if you provide enough keys in advance and cycle through them slowly enough (say, one per week), you can be sure that most radios in regular use will get an updated key set before that key goes into use.
The problem with leaving an XM radio off for a long period of time is that you'll miss these key updates. While the radio may not have been specifically deactivated, the lack of any valid decryption keys is basically the same thing in the end. If you miss the deactivation signal, you can listen so long as you have valid keys. But if I were architecting the security of XM's system, I'd have arranged things so that the "deactivate now" signals are sent periodically for at least as long as the end of the validity period for the longest-lived key available when the receiver was unsubscribed. So, if you listen while your keys are still valid, chances are good that you'll get deactivated by having your crypto keys overwritten. If you aren't listening, this can't happen, of course--but you also don't have access to the signal.
For legitimate subscribers: if you DO happen to lose service on an infrequently-used radio because it didn't receive an activation signal in a long time, XM has a web page that will let you cause the relevant data for your radio to be sent quickly, rather than waiting for it to roll around in periodic update cycle.
SecurID cards generally don't require a PIN be entered into the card. There is a variation of the SecurID which does use a PIN entered on the card, but it's rarely used and all of the validation is done server-side. The PIN algorithm it uses is really simple, too; it permutes the displayed number in a way that can be calculated mentally in less time than it takes to enter the PIN using the buttons on the card. Surprisingly, this doesn't have an effect on the overall security of the system; the real strength is in the pseudo-random sequence generated by the card itself.
The RIAA's (and Valenti's) idea of what is right is even more twisted than that. They have stated that making a copy of a CD for one's car is wrong. In their eyes, each and every stereo should have a seperate purchased copy.
Just one copy per stereo? RIAA is leaving money on the table by forgetting that most car audio systems have more than two speakers and can carry more than one passenger!
I saw this in the Washington Post yesterday and thought it interesting enough to send the reporter (Kathleen Day) a note, which follows, summing up my thoughts on the matter. I haven't heard anything back yet (and I don't necessarily expect to).
-Phil
Ms. Day:
I find it absolutely fascinating that problems such as the one you encountered are treated primarily as a user education issue. It's true that there are some things that everyone needs to know in order to use a computer. It's also true that savvy users can often avoid security mistakes. But one wonders, "Why is it that users *have* to be security-savvy in order to effectively use their computers?" I'd submit that the problems you wrote about are mostly the result of design flaws and not naivete. In many ways, I think the computer industry has set the bar far too low by blaming users for problems it has created. Put another way: what would you think if you had a car that would sometimes break down without warning if you drove it on the highway without first buying additional parts?
As I see it, there are two design weaknesses that contributed to the problems that you wrote about. First, basically anything you do on a machine running Windows is done with full administrative privileges. In one way, this makes sense: you own the machine, so you should be able to do anything you want with it. The problem, however, is that this blind trust allows malicious software to do pretty well whatever it wants. Most other operating systems (Mac OS X, Linux, and Unix) require you to take some special action (usually typing a password) in order to install software or alter the operating system. While this can't prevent you from choosing to install malicious software, it makes it quite difficult to do so unknowingly. To stretch the car analogy a little further: people can't modify your car's engine without your knowing about it because you have to open to hood in order to reach it. Computers should work the same way.
The second problem is that Windows doesn't make a strong distinction between programs (the applications that you run) and data (documents and the like). This makes several attacks a lot easier, as malicious programs can sneak onto your machine by masquerading as data when you are browsing the Internet. For most non-Windows operating systems, there's something that you have to do explicitly to say, "This is a program and it's OK to run it." If Windows has these protections, there still wouldn't be anything to stop someone from maliciously sending you data you didn't want--but your computer wouldn't be able to then run that data as if it were one of your programs.
It's a mistake to say that anything is totally secure. There have been (and will continue to be) successful attacks on operating systems other than Windows, of course. But I think it's a mistake to think that Windows has so many (and such severe) attacks just because of its dominant market position. True, it's low-hanging fruit for those with a malicious bent. But it's also so much easier to attack Windows because of the way it's been designed.
The very concept of a computer virus depends on both of these two factors. Take away the administrative powers, and the virus has little if anything to infect. Remove the confusion between programs and data, and it becomes much more difficult for malicious software to spread. Many regard it as unnecessary to run antivirus software at all on non-Windows systems. While I'm personally not sure that's a good idea, it does give one an idea of the relative security levels involved.
I think these security problems may ultimately threaten Microsoft's market position. The bad design decisions that are part of Windows weren't made because Microsoft is dumb (quite the contrary: they employ a lot of very smart developers and architects). They were made for market-driven reasons. Lots of old software (dating back to old versions of Windows and the even older days of MS-DOS) simply won't run in a more secure environment. As
For those interested in trying VMS on Linux using the SIMH emulator (entertaining if you once used it), I've written a set of installation instructions that might be of some use.
Phil
Re:Why IT is annoying
on
Are You Annoying?
·
· Score: 2, Interesting
Also: "Sure, you can have root (or domain admin) access. What's your cell phone number? We need it because it's our policy that anyone with administrative powers be reachable by our help desk team on a 24x7 basis."
I can't claim to have come up with the idea, but I can say that I've tried it; this requirement really does lead to fairly intelligent self-selection so long as the "sure, you can have it" offer isn't made to those who are obviously unqualified.
Slashdot Mirror
Dan,
I agree with your basic conclusion: the heat one feels when using a cell phone or handheld transceiver is due to the fact that much of the energy being consumed isn't being converted into RF. It's hard to make a transmitter that converts more than 30-40% of the energy consumed into RF, and efficiencies as poor as 10% or so aren't unusual.
But I did want to make a gentle technical correction. Your message suggests that there's very little absorption in the 2M (144-148 MHz) band used by your HT; this is actually incorrect.
Heating from RF is can be quantified by the specific absorption rate (SAR) of the body being heated when exposed to RF. As the name suggests, it's the amount of RF that gets absorbed by tissue in the body (which results in heating). It's usually measured in watts per kilogram.
It actually takes LESS power at VHF frequencies (like 2 meters) to reach a given SAR than it does at UHF, microwave, or HF. It's a result of resonance effects as the wavelength approaches the size of the human body.
Take a look at the FCC's OET Bulletin 65, which specifies the power levels at which you have to undertake an RF safety review of your amateur station. These power levels are derived from the amount of energy at a given frequency required to achieve a specific SAR. Note that for VHF, just 50 watts is enough to trigger the requirement. At HF frequencies, the levels are often much higher (500 watts for the 40M band, for example). In the 13cm band (2.4 GHz), you need to be operating at 250 watts or above before the FCC feels you need to do a routine evaluation for RF safety.
Greg Lapin, N9GL, has written about this fairly extensively on the ARRL Web site if you (or anyone else) are interested in learning more.
Once again, I'm not challenging your conclusion that most of the heat from holding a phone or radio transmitter is simply waste heat. And I'm certainly not asserting that there's any danger in using a cell phone or HT. But I thought you might be interested to know that the body actually is heated MORE by a given power level in the VHF range than it is by the frequencies used by cell phones.
Phil
I really feel for all the folks who have to deal with this outage; it's no fun at all!
A client of mine had a number of servers in a Sterling, Virginia data center managed by Verio/NTT. It's a good data center and seems to be well-run.
Last September, the data center experienced two complete power failures in the span of three days. To their immense credit, data center management was straight with customers about what had happened. For those who might be interested, their statements about the problem appear here.
My point? Make sure you know how to bring your systems back up from a completely cold start, and that you find a way to test this periodically. While we work to ensure that this sort of situation occurs rarely, the fact remains that these sorts of failures DO occur, and they're not as uncommon as the sales and marketing folks would like you to believe.
Phil
In the security business, a lot of the danger from IT employees comes from a class of attack known as "abuse of authority." It's near-impossible to prevent through technical measures, since the people in question need the elevated privileges in order to do their jobs. A careful program of auditing can often detect these abuses after they've occurred, however.
I had a situation occur a few years ago in which I had to fire a trusted and valuable staff member for snooping through a senior manager's email. Another staff member actually detected this when he printed a copy of the email, and it came out of the printer in his home office even though he was on travel. This came to my attention very quickly, and we reviewed audit logs that we'd put in place earlier and found plenty of evidence of his snooping. It pained me to fire the guy--he was smart, ambitious, and held up really well under pressure. But in the end, I concluded that a slap on the wrist would just send the message to other team members that it was OK to cheat until caught for the first time. I suspect that it was the right move for him, too; our sudden, decisive response to his lapse in judgment doubtless made an impression.
So, some advice to IT managers: ensure that there's an audit trail for all privileged activity. You'll detect and stop abuse if it's going in, and will deter staffers from being tempted to misuse their rights.
Phil
The fine article is interesting, though it sure reads a bit like the sort of article mentioned in Paul Graham's excellent essay "The Submarine". The suit is back!
It's about time for the financial services industry to step up and take responsibility for designing a payment infrastructure that can accomodate the current threat environment. A sixteen-digit reuseable number can't provide adequate security, even when coupled with real-time billing address and CVV2 tests. Payments need to be authorized individually by the accountholders, and these authorizations need to be tied to a specific date, time, merchant, and amount (or in the case of recurring payments, a time span, number of payments, and maximum aggregate amount). In this scheme, leakage of an account number doesn't connote authorization for payment--and leakage of a payment authorization doesn't enable re-use by others.
It will be hugely difficult and very expensive to make this change, of course, as it involves replacing a great deal of infrastructure. But ultimately it will be required due to the simplicity of fraud using today's technology. It's gotten to the point where most of the difficulty and expense isn't the technology for payment authorization; it's instead the cost associated with the changeover itself and with retraining consumers and merchants.
So, from where I sit, it looks like the costs of fraud being absorbed by the financial services industry (and, of course, being passed on to consumers in the form of higher fees) aren't being offset by a decrease in the eventual cost of making the system secure. It's time for the financial services community to take responsibility, then: accept the fact that it will be difficult and expensive to make the change, but also accept its necessity and inevitability.
Interesting test - thanks for trying it!
My suspicion is that the CPU is a whole lot faster at performing an XOR on a relatively large block of memory than it is at doing a correspondingly larger number of XOR iterations on a few bytes. In particular, the MMX instruction set extensions were designed to handle logical operators on large blocks efficiently. By doing it a little at a time, you spend a correspondingly large amount of time handling your loop counter and associated comparisons.
At any given point in time, your system is in one of three states:
- partially idle (there's unused CPU and disk I/O capacity),
- CPU-bound (the CPU is fully utilized but there's disk I/O bandwidth available), or
- I/O bound (the CPU has spare cycles, but the disk can't provide data fast enough to put them to use).
I suppose that a heavily overloaded system could be both CPU and I/O bound, but it would require a mix of CPU- and disk-intensive processes that isn't usually seen in practice.Let's ignore the partially idle case, in which there's ample disk and CPU to go around, as it doesn't really matter in this scenario whether the CPU or disk controller perform the XOR operations.
In the case of a CPU-bound process, you're going to incur the additional CPU overhead of the XOR operation. XOR is almost absurdly fast, particularly if the data is in the CPU's cache. I'm pretty sure that modern CPUs execute XOR on at least one byte per clock cycle. But let's say, for the sake of argument, that it takes three cycles per byte. On a CPU clocked at 3 GHz, you'd be able to perform XORs on one gigabyte of data per second if you ignore memory and cache issues. Given moderate memory bandwidth, you're also able to transfer over a gigabyte of data to or from the CPU per second. Given a more reasonable amount of data (say, one megabyte, to transfer), you'd be looking at a CPU impact of around one millisecond to perform the XOR. That's a 0.1% impact at most in a CPU-bound environment, and that's presuming you're doing a megabyte of disk I/O per second.
Now let's look at the I/O-bound case. Here, the CPU is sitting around waiting for the disk I/O to finish up. In this case, it clearly doesn't matter who's doing the XOR operations, since the CPU isn't fully utilized. PCI bus utilization is going to be increased by up to 100% (in the worst-case scenario involving drive mirroring; the worst-case RAID5 scenario is a 50% increase). A typical server's 66 MHz 64-bit PCI bus has a capacity of around 533 megabytes per second (PCI Express increases this dramatically, but let's stick with pessimistic examples for now). At the moment, a SCSI bus tops out at 320 megabytes per second, and those transfer rates are only achievable with at least four drives on the channel and an almost exclusively sequential I/O mix (the best-case numbers for a 15,000-RPM drive are about 100 megabytes/second). So there's generally bus bandwidth to spare.
You raise a number of other points in your note that are potentially issues (hot swappability, for example). But I've become convinced that the CPU/machine performance argument against software RAID really only made sense when CPUs/memory/bus bandwidth were much more constrained.
We're obviously in violent agreement here.
;-)
Your point regarding public-key crypto is particularly well-taken. Since the authentication we're talking about is between two parties (car and key) that have been introduced previously, a shared-secret form of authentication would work fine.
And I'm in complete agreement that an inexpensive and low-powered processor can perform cryptographic functions like DES/3DES, SHA-1, or MD5 very quickly.
You've also made an excellent point regarding when authentication actually occurs. The car definitely senses the key autonomously; exterior lights on the car illuminate when it's nearby. I'm not sure this first round of illumination depends on having the correct key, though, and I'm pretty sure a second round of communication takes place when the handle is touched. This obviously requires some additional experimentation!
Thanks again for your comments, even if you've violated a long-standing Slashdot tradition by supporting your assertions with actual facts!
Phil
Thanks for the specifics. I haven't worked with smart cards in the last couple of years, so it's good to get some up-to-date information!
I concur that key generation time is basically irrelevant, since it's done so rarely (presumably only when the key is introduced to the vehicle).
But even a 417ms budget for authentication (car sends an "encrypt this random token with your private key and then send it back" challenge) is most likely too long. One of the operations I didn't mention involves unlocking the car. When you grab the door handle, you touch a contact point on the back. The car interrogates your key; if you have it (and it passes authentication), the car unlocks. In practice, this means you walk up to the car, grab the door handle, and pull. A couple of beeps is really the only way you know the car was locked in the first place. Fast as public-key crypto is on modern cards, 0.4 seconds is too long to wait for this operation to seem natural. It's probably too long to wait for the ignition keyswitch to react, too.
One thing that I should emphasize strongly: I have no idea whether there's any strong crypto at all going on between the key and the car when using the battery-powered transponder! It's entirely possible that the long-range transponder mode is doing something much less secure. For example, the car might be saying, "take this random token, encrypt it with a pre-shared symmetric key, and send it back." In this case, pretty well anything would have the processing horsepower to pull it off, and a battery would only serve to increase range, as you pointed out in your response to my original comment.
Phil
Sorry, I wasn't very clear! Thanks for catching my error.
I should have said that the car refuses to let you park and lock it while leaving the key behind. The semantics of this are fairly complex: the car won't lock if a door is open and the key is in the passenger compartment (i.e. you're getting out of the car and click the lock button). There's also a lock button on the outside of the car's door handle; that, too, won't work if the key is inside, regardless of whether the door is open or closed.
It's almost impossible to do this unknowingly; there's an error beeper that sounds whenever the car senses that the key is in the wrong place (in the passenger compartment/trunk when locking the car, or when removed from the passenger compartment while the engine is still running). In the latter case, the car can still be driven (though the beeper will drive you crazy). Once stopped, though, it won't restart.
The car can be locked from inside with the doors closed (this will arm the alarm if it's done while the car is parked and turned off). In fact, putting the transmission in gear will normally lock the car automatically.
Phil
No, it's just a coin cell in the key itself; it's changed by the user just like any other battery-operated device.
You're absolutely right: smart cards with no batteries can indeed do these things. But they typically can't do these things very quickly. This is especially true of public-key operations like RSA; DES (and, therefore, 3DES) was designed to be computationally efficient.
There's a relationship between processing speed and power consumption. Having the battery allows the processor to run more quickly than is possible in a contactless smart card.
In addition, there's also a power and bandwidth issue: having more RF output power will generally allow you to send more data in a given unit of time.
This matters in an automotive environment; the driver expects to be able to turn the ignition switch and have the car immediately start. Waiting some number of seconds for a key exchange to occur, while more secure, isn't likely to be acceptable to the end user. Having more power available for the processor makes it possible to do something more sophisticated in the same amount of time.
It's completely possible, of course, that the battery only increases the range in this application. But, given a response time constraint, the availability of more current will give the designer of the system additional flexibility when choosing between cryptographic schemes.
Phil
A battery failure is no big deal, actually.
One of the things the key transmits is a battery status, so you'd have to ignore a "low battery" warning message for a while in order to wind up with a completely dead battery.
Even then, you can start the car by putting the key into the ignition. In that case, a short-range unpowered transponder (presumably of the sort described in the article) is used to authenticate the key. You just lose the convenience of being able to leave the key in your pocket/briefcase/purse until you replace the battery.
Actually, the Lexus keys just use a reverse cut. The photo posted is of a blank (uncut) key. Here is a photo of a key that's been cut; note that it has a pattern that can be viewed/impressioned easily. It's still more secure, though, as it's an asymmetrical cut with pins on BOTH sides of the keyway.
Some of the newer Lexus keys do use RFID exclusively for starting the car. The key has a battery in it, and is designed to be queried from a significant distance (several feet), as it does NOT need to be in the ignition to operate. The car also refuses to lock if the key is in the passenger compartment, and the trunk won't close if the key is inside. There's a light on the key that illuminates when it transmits. Based on observation, it looks like the key won't respond unless it's queried directly, so capturing data from one of these keys would involve a small bit of additional complexity. I suspect that the presence of the battery allows much more robust encryption, as well.
Phil
I'm a little suspicious of this story.
I drive an LS430. The navigation system, phone, audio system, and air conditioning control system are driven by a system made by Denso. I can't say with certainty what operating system it's running, but it looks like an evolution of a design they've had going since at least 1998.
The Bluetooth interface is rather limited. You can use the hands-free capability after pairing it with your phone. You can transfer a phonebook using the OBEX profile. To my knowledge, none of the other Bluetooth profiles are supported--most notably the Object Push Protocol (OPP). In order to get OBEX phonebook transfers to work, you have to put the car phone system into a special mode; it won't just blindly accept transfers--even from paired devices. If this system is running Symbian and is really vulnerable, I wonder if it manifests itself only when attempting to transfer phonebook entries from an infected device.
The same navigation system is used in a number of cars beyond the Lexus LS430 and LX470. The SC430, GX430, and RX330 use the same Bluetooth system, as does Toyota's Land Cruiser and Prius.
Phil
Thanks for your thoughts on this.
I completely agree with you about "living on the edge;" that's the consumer's fault, not a card issuer's.
You're also absolutely correct that without a physical signature, a merchant doesn't have a guarantee of payment from the card issuer. But your point underscores even more strongly the need for a better system than we've got right now. Otherwise, the message is essentially, "all electronic commerce is a crapshoot; work face-to-face if you want to have any hope of getting paid."
I'd also argue that fraud isn't really just a loss for the merchant; those losses are baked into the cost of every product the merchant sells--just as is the case with shoplifting, inventory shrinkage, etc. Tighter controls will ultimately benefit everyone involved in the transaction.
While there's been plenty of talk about responsible protection of one's personal data (being careful about supplying information to an online site, for example), it sure seems like there are two areas of responsibility that are being overlooked.
First, it's about time for the financial services industry to step up and take responsibility for designing a payment infrastructure that can accomodate the current threat environment. A sixteen-digit reuseable number isn't the answer, even when coupled with real-time billing address and CVV2 tests. Payments need to be authorized individually by the accountholders, and these authorizations need to be tied to a specific date, time, merchant, and amount (or in the case of recurring payments, a time span, number of payments, and maximum aggregate amount). In this scheme, leakage of an account number doesn't connote authorization for payment--and leakage of a payment authorization doesn't enable re-use by others.
It will be hugely difficult and very expensive to make this change, of course, as it involves replacing a great deal of infrastructure. But ultimately it will be required due to the simplicity of fraud using today's technology. It's gotten to the point where most of the difficulty and expense isn't the technology for payment authorization; it's instead the cost associated with the changeover itself and with retraining consumers and merchants.
So, from where I sit, it looks like the costs of fraud being absorbed by the financial services industry (and, of course, being passed on to consumers in the form of higher fees) aren't being offset by a decrease in the eventual cost of making the system secure. It's time for the financial services community to take responsibility, then: accept the fact that it will be difficult and expensive to make the change, but also accept its necessity and inevitability.
Second, it's time for the users of Internet connections to take responsibility for the devices they connect. While I'm sympathetic to the fact that grandma probably isn't a PC administrator, and isn't aware that her machine was 0wn3d two years ago and has been a spam zombie ever since, I don't think we as an Internet-age society should simply absolve users of any responsibility for the health of their machines. One reasonable parallel is a burglar alarm. In the locality where I live, you're allowed one or two false alarms per year, then you start racking up fines. This makes sense to me: it's not good to penalize the innocent and ignorant unwittingly, but those that continue to consume resources (in this case, police time) are given an economic incentive to improve their infrastructure. It would have to be done carefully, but treating long-term spam zombies as civil infractions might provide the incentives necessary for users (and, of course, the vendors that serve them) to improve their security profile. Just as with the institutional changes in the financial services arena discussed above, this would be really difficult to do, particularly given the borderless nature of the Internet. But I'm not sure that difficulty is a good enough reason to avoid requiring computer owners take reasonable responsibility for their use.
Thoughts and constructive criticism are welcome.
Phil
I, too, am using the Aircard 5220 under Linux using Phil Karn's instructions.
Verizon's 1XEVDO service has been launched in a lot of markets now. It's comparable to DSL throughput (base data rate of 2.4 megabits/second with real throughput of 300-500 Kbit/s), though latency isn't comparable to a wired connection.
Where 1XEVDO service isn't available, though, the card *will* automatically fall back to using 1XRTT service, which is deployed basically everywhere. Data rates are much slower (144 Kbit/s base rate, with actual throughput of 35-40 Kbit/s). I don't if the previous poster has had problems with the EVDO-to-RTT fallback or simply hasn't had occasion to try it, but I've had no problems with it.
Phil
I don't think this would work, actually.
XM's data stream is encrypted. I have no inside knowledge of the matter other than the fact that I'm a paying subscriber to the service. That said, I imagine that what's sent down to your receiver every so often is the crypto keys required to decrypt the audio channels (I'd guess one key per channel or service tier, to allow for premium services, sports blackouts, etc.).
Since this audio decryption key is going to be the same for every radio, it's further encrypted against a unique key in the radio. Your radio receives a broadcast containing its serial number and an encrypted key. I wouldn't be surprised at all if there were actually multiple keys sent, along with validity periods (use this key until time X, then this key until time Y, etc.). Your radio then uses its unique key to decrypt the shared keys, and stores them away in its memory.
Providing multiple keys in advance makes things a lot easier when you can't guarantee that a particular receiver will be on to receive the key; if you provide enough keys in advance and cycle through them slowly enough (say, one per week), you can be sure that most radios in regular use will get an updated key set before that key goes into use.
The problem with leaving an XM radio off for a long period of time is that you'll miss these key updates. While the radio may not have been specifically deactivated, the lack of any valid decryption keys is basically the same thing in the end. If you miss the deactivation signal, you can listen so long as you have valid keys. But if I were architecting the security of XM's system, I'd have arranged things so that the "deactivate now" signals are sent periodically for at least as long as the end of the validity period for the longest-lived key available when the receiver was unsubscribed. So, if you listen while your keys are still valid, chances are good that you'll get deactivated by having your crypto keys overwritten. If you aren't listening, this can't happen, of course--but you also don't have access to the signal.
For legitimate subscribers: if you DO happen to lose service on an infrequently-used radio because it didn't receive an activation signal in a long time, XM has a web page that will let you cause the relevant data for your radio to be sent quickly, rather than waiting for it to roll around in periodic update cycle.
Phil
SecurID cards generally don't require a PIN be entered into the card. There is a variation of the SecurID which does use a PIN entered on the card, but it's rarely used and all of the validation is done server-side. The PIN algorithm it uses is really simple, too; it permutes the displayed number in a way that can be calculated mentally in less time than it takes to enter the PIN using the buttons on the card. Surprisingly, this doesn't have an effect on the overall security of the system; the real strength is in the pseudo-random sequence generated by the card itself.
Just one copy per stereo? RIAA is leaving money on the table by forgetting that most car audio systems have more than two speakers and can carry more than one passenger!
I saw this in the Washington Post yesterday and thought it interesting enough to send the reporter (Kathleen Day) a note, which follows, summing up my thoughts on the matter. I haven't heard anything back yet (and I don't necessarily expect to).
-Phil
Ms. Day:
I find it absolutely fascinating that problems such as the one you encountered are treated primarily as a user education issue. It's true that there are some things that everyone needs to know in order to use a computer. It's also true that savvy users can often avoid security mistakes. But one wonders, "Why is it that users *have* to be security-savvy in order to effectively use their computers?" I'd submit that the problems you wrote about are mostly the result of design flaws and not naivete. In many ways, I think the computer industry has set the bar far too low by blaming users for problems it has created. Put another way: what would you think if you had a car that would sometimes break down without warning if you drove it on the highway without first buying additional parts?
As I see it, there are two design weaknesses that contributed to the problems that you wrote about. First, basically anything you do on a machine running Windows is done with full administrative privileges. In one way, this makes sense: you own the machine, so you should be able to do anything you want with it. The problem, however, is that this blind trust allows malicious software to do pretty well whatever it wants. Most other operating systems (Mac OS X, Linux, and Unix) require you to take some special action (usually typing a password) in order to install software or alter the operating system. While this can't prevent you from choosing to install malicious software, it makes it quite difficult to do so unknowingly. To stretch the car analogy a little further: people can't modify your car's engine without your knowing about it because you have to open to hood in order to reach it. Computers should work the same way.
The second problem is that Windows doesn't make a strong distinction between programs (the applications that you run) and data (documents and the like). This makes several attacks a lot easier, as malicious programs can sneak onto your machine by masquerading as data when you are browsing the Internet. For most non-Windows operating systems, there's something that you have to do explicitly to say, "This is a program and it's OK to run it." If Windows has these protections, there still wouldn't be anything to stop someone from maliciously sending you data you didn't want--but your computer wouldn't be able to then run that data as if it were one of your programs.
It's a mistake to say that anything is totally secure. There have been (and will continue to be) successful attacks on operating systems other than Windows, of course. But I think it's a mistake to think that Windows has so many (and such severe) attacks just because of its dominant market position. True, it's low-hanging fruit for those with a malicious bent. But it's also so much easier to attack Windows because of the way it's been designed.
The very concept of a computer virus depends on both of these two factors. Take away the administrative powers, and the virus has little if anything to infect. Remove the confusion between programs and data, and it becomes much more difficult for malicious software to spread. Many regard it as unnecessary to run antivirus software at all on non-Windows systems. While I'm personally not sure that's a good idea, it does give one an idea of the relative security levels involved.
I think these security problems may ultimately threaten Microsoft's market position. The bad design decisions that are part of Windows weren't made because Microsoft is dumb (quite the contrary: they employ a lot of very smart developers and architects). They were made for market-driven reasons. Lots of old software (dating back to old versions of Windows and the even older days of MS-DOS) simply won't run in a more secure environment. As
Thanks; I really appreciate your kind words!
Phil
For those interested in trying VMS on Linux using the SIMH emulator (entertaining if you once used it), I've written a set of installation instructions that might be of some use.
Phil
Also: "Sure, you can have root (or domain admin) access. What's your cell phone number? We need it because it's our policy that anyone with administrative powers be reachable by our help desk team on a 24x7 basis."
I can't claim to have come up with the idea, but I can say that I've tried it; this requirement really does lead to fairly intelligent self-selection so long as the "sure, you can have it" offer isn't made to those who are obviously unqualified.
Phil