That's what they did in The Net. If you look closely, most (all?) of the IP addresses used had one or more octets above 255, making it invalid. Pretty good idea, if you ask me.
Unless the spammer's "ISP" *is* the spammer, or the ISP is spam-friendly. At that point you have little choice but to go up another level. I've had to do that quite frequently.
Most people use IRC to chat with new folks, not to establish a "club room" where the same, select gang meets. It's kind of hard to meet a bunch of new people with similar interests on a server with such a small number of users, so they use a large, established one.
The whole hostname masquerading thing has been discussed on just about every IRC network. Those that choose to support it do so. Those that don't have their reasons.
The web equivalent of an IRC relay would be one of those anonymizer services. They could easily have chosen to use one of these if they were truly worried about their identity.
I'm amazed at how many posters on this thread are running on the "it's another CPU ID" gripe when that has no basis in reality.
It's because of the submitter's "summary" and "michael"'s subsequent editorial. It's obvious he didn't read the article. He just saw the "CPU ID" phrase and went ballistic, like so many uninformed privacy nuts that post here regularly.
I really wish the Slashdot authors would try to be a little less biased when it comes to the articles they post here. Slashdot has become MUCH too editorialized, which wouldn't necessarily be *all* that bad, except THEY DON'T DO A GOOD JOB EVEN AT THAT. They base their editorial comments and slurs on stupid/uninformed assumptions based on little/no information. As much as I love Slashdot, it will never be a true journalistic site until it can replace its poorer "authors."
I'm not sure I understand what you mean by "color range". The main thing to account for from an ergonomics standpoint is a) eyestrain due to the differing brightnesses of a monitor as compared to ambient room lighting; and b) different definitions of "white". Your brain tends to "adapt" to different lighting conditions, changing its own internal definition of "white" to match it as close as it can to the room's lighting. Having your monitor's "white" be a bluish color relative to your room light causes your eyes and brain to have to do a bit more work keeping colors sorted out. Plus, for those of us that do screen -> print work, color matching becomes a necessity.
I'm not sure how this affects the "color range" per se. It should affect color *correction*, sure. If you're worried about dropping your brightness/contrast too low for good gaming (where a bright color is meant to be seen as an "uncomfortably" bright light source), adjust your monitor. The brightness/contrast controls are meant to be easy to get at. *shrug*. Many games also have an internal "gamma" setting that could be used to compensate a for a monitor's conservative settings in this fashion.
The keys are stored in the hardware. The article states that in order to access these hardware features, you will have to provide a PIN to the software to gain access to the keys.
Without this manual step, it would become possible for malicious programs to digitally sign/encrypt things you didn't intend to sign/encrypt.
I will state that all things (this is stated liberally, I am sure that I am wrong in certain cases) that has to do with hardware can be discerned/extracted using software.
The reason private keys can't be "pried" from hardware products is because these hardware products provide no mechanism to retrieve the private keys.
It's the same reason you can't write a program to command an Intel CPU to change colors. The chip simply isn't capable of doing it.
When constructing something like a cryptographic chip, just build functions into the chip that you need. You don't want the private key to be exposed, so don't create a "return_private_key" opcode when designing the chip. There are probably things like "return_public_key", "encrypt_text_at_this_memory_address", etc. Unlike software, you can't just write a program to examine the details or inner workings of a piece of hardware. The hardware has to be explicitely programmed to volunteer that data.
Hardware data encryption has been something pushed for quite a while now. It's not that it's faster or more convenient than software solutions, and *certainly* it's not because the hardware is more adaptable. It's because the hardware version is incapable of allowing the private key to be discovered. Whenever you use software, the public and private keys are stored somewhere on the hard drive in a not-so-cryptographically-secure form. This means it can be found and stolen by a malicious program. That simply isn't possible with hardware solutions.
[I HATE the way posting seems to default to HTML now and strips out all the carriage returns.]
If you sign up for a Slashdot account, the default posting behavior is saved for you. We even have the ability nowadays to post anonymously via a checkbox...
Do you have any idea how hardware based encryption products work? The whole reasoning behind hardware-based encryption is *because* it's not possible for software to retrieve the private keys! That's the whole purpose behind doing it. If private keys were somehow able to be retrieved, there'd be no point in doing it with hardware at all, because it has no advantage whatsoever over software solutions. This is a fundamental design requirement, and is EASY to assure.
I think you're being very rude here. The only reason I was saying 256 bits is plenty for me is because current encryption products use FAR LESS SECURE keys than what this chip is providing. I wasn't suggesting that you be a good boy and be content to use it. If you feel you have data that requires more security, USE A MORE SECURE PRODUCT.
The solution IBM provides should be the best possible. This isn't it.
A previous poster noted that this chip uses a 256-bit key for data encryption. A typical HTTPS/SSL connection uses a 40-bit key (with 128-bits implemented in "unexportable high-security" browsers).
I don't know about you, but this is more than adequate. IBM says as much and indicates if users need something more secure, they're free to augment this system with things like smart cards and the like.
If you're so concerned that people are getting a false sense of security with this device, you should be working to warn them about the dangers of secure web sites, which are significantly less "secure".
If you want to decrypt someone else's encrypted data nowadays, it's to your advantage to somehow gain access to their system and find a way to steal their private key instead of trying to "crack" it. By doing this in hardware, this becomes impossible. This is why hardware encryption schemes are so much more secure than equivalent software ones.
Hell, why not outlaw IP addresses while you're at it.
These things are necessary for networks to function.
As far as the hardware encryption chip goes, do a bit more reading and you'll discover that this really isn't something that *needs* to be disabled. The whole "it's another attempt to brand our computers with an ID" argument is just silly. The only thing that this chip does is hardware-based encryption/decryption of data, much like an MPEG decoder card. The only difference is that, for this chip to work, you'd want to publish the public encryption key so people can send you encrypted messages and you can send others encrypted/signed messages of your own. It's NO different than using a software-based encryption solution, except that with hardware, it's impossible for someone to "steal" your private key.
You assume that these encryption keys are associated with you personally. What you don't realize is that it's very common for secure HTTP sessions and SSH connections to generate new keys all the time.
So long as the remote end has *some* public key that represents your system, they can verify your messages and validate your signatures.
The difference between this hardware scheme and existing software schemes is that it's theoretically possible for a malicious program to obtain your private keys stored on your system. It's not possible to do this if these keys are stored in hardware.
First of all, why hardware? It's just as easy to implement the crypto in software. And software encryption can be much more flexible, handling larger key sizes for the ultra-paranoid, or forty-bit keys for the clueless.
The whole point behind using hardware crypto is that it's impossible for software to recover private keys that are stored in hardware. With software-based crypto, there's always the (small) chance a trojan/virus will discover and recover your private encryption keys.
Finally, why the hell would you do this when there was so much controversy over the PIII ID? I would figure that IBM has some good PR and advertising folks-- how did this one slip out the door?
Because this crypto chip has nothing to do with ID's. All it does is provide encryption and digital signing services. To use these services, you must provide a PIN to software, which enables the features. It becomes an explicit user-initiated process, not something that can be maliciously hidden in the background.
The whole point is to allow you to digitally sign and encrypt data. What's the point in building a hardware system if malicious code could digitally sign stuff on its own, without your approval?
It's rather commonplace for people to upgrade their desktop PC's every few years. CPU's change, motherboards change, hard drives change. To tie software to any of these components seems rather stupid to me.
The only reason this sort of thing worked with older mega-server architectures in the past is because those platforms didn't have the upgrade rate of today's PC's. Plus, even if an upgrade *was* performed, all you usually had to do was contact the software vendor and let them know. A new software key was re-issued in short order.
With the upgrade rates of today's systems, I can't imagine a software company volunteering to create a staff of people set up to handle the enormous volume of requests for new keys as people upgrade hardware.
This is *not* a "CPU ID" chip. It is designed to do hardware-based public/private key encryption. To use these hardware features, you must supply a PIN/password to enable access to your key pairs. Thus, it is an explicit user-initiated process.
To suggest that web site owners will start requiring people to use these keys is totally absurd. Why in the world would web site owners voluntarily reduce their client base to less than 1% of its current base (those that have machines with these chips)?
People are using the same arguments they used against the Intel PIII CPU ID thing, when really the two situations aren't alike at all.
If you don't want to use the encryption offered by the hardware, DON'T. Stick with PGP or whatever other software-based solution you're using today. The only difference is that in the hardware implementation, it becomes impossible for trojans/virii/malicious programs to steal your private PGP key.
What makes you think this is possible? By storing the private key in hardware, it becomes impossible to access via software.
The only way the key could be discovered is by a cracking effort. At 256-bits (as one poster indicated for encryption, and 1024-bits for digital signatures), it's going to take a long time for that to happen.
How are you going to be able to communicate to the powers that be that your key has changed, and not only that, you could just change your key and all your new transmissions would be unreadable...
Uhh, the same way that people do it today with software encryption products (like PGP). Just pass out your new public key and stop using the old key pair.
Better yet, J. Smith over here invents a utility to reflash the chip with an arbitrary "identifier" and people can now pose as you:(...
You assume that this chip can be "upgraded". It's quite likely that this chip is entirely hardware-based. No "flash" upgrade at all. That would leave it open to the attack you mentioned. The whole idea is to keep the chip completely isolated from software.
If you had read and understood the article, you would know:
By placing the private key in *hardware*, it no longer becomes accessible by software. It is impossible to recover a hardware-based private key via software.
The only way a hardware-based key can be discovered is if it's cracked. Seeing how distributed.net has been working on cracking the latest 64-bit RC5 key since the latter part of 1997, I don't think we have to worry about these hardware keys being cracked any time soon.
Dude, I don't know what sort of top secret information you're planning on distributing, but 256 bits is plenty for me. If this encryption is honestly inadequate for your needs, I'd seriously suggest that you lock your computer in a safe someplace and never ever connect it to any form of computer network. Hell, you might want to dip the hard drive into some molten lead and throw into the middle of the Atlantic if you're that worried.
HTTPS (SSL) predominantly uses 40-bit encryption. "High security" versions of the same thing run at 128-bits. The last I checked, the "default" PGP key length wasn't anywhere *near* 1024-bits, which this chip supports.
Again, it's all a matter of *degree*. True, there is software out there that uses key lengths a lot longer than what this chip offers, but you won't find that software in mainstream browsers and e-mail clients, which means it's useless to normal people.
Additionally, you seem to forget the whole purpose of moving encryption into hardware: It's impossible to recover the private key via software. Today it's theoretically possible for a trojan or other malicious programs to snoop around your hard drive, find your software-based PGP private key ring, and from there, somehow recover the private key. This is not possible with hardware-based encryption, hence its attractiveness.
the software can be used to track people wherever they go
A PIN/password is required to activate features of this encryption chip. Thus, encrypting or digitally signing something requires explicit user intervention.
There is no "ID" that is sent out by evil software. The only thing I can think of that might work in this fashion would be the public key, which is meant to be distributed anyway. If I were writing a trojan or an evil program to track users, I can think of a few better ways of doing this than relying on something only a small percentage of consumers is going to have available (like, say using the MAC address, Windows registration codes, e-mail addresses, etc., etc.)
I don't think you quite understand how this chip is supposed to work.
So everything made on a computer can be traced to that computer.
This isn't correct at all. The digital signing/encryption process requires the user to enter a PIN/password. The user must *explicitely* make the effort to digitally sign a document or to encrypt data. This isn't something that can just be hidden in the background for malicious or rogue software companies to take advantage of.
Though to be fair, it's certainly possible that this PIN requirement could be bypassed by a trojan/malicious coder. I'd be interested to hear how IBM plans to keep that from happening.
Furthermore, what happens when 128-bit keys are no longer secure enough and you need to move to 256-bit keys?
I believe a previous poster mentioned that this chip was capable of 256-bit encryption and digital signatures up to 1024-bits. Granted, it will be obsoleted in several years, but it's more than sufficient for items not of a super-sensitive nature. The article explicitely states that it should be adequate for around 80% of their customers. The remaining 20% apparently have needs for stronger encryption and either won't use this hardware chip, or will use it in conjunction with something else (as the article states).
Nobody's *requiring* this chip to be used. The whole idea is that the hardware chip completely hides the private key, making it impossible to recover by software (thus exposing data encrypted with it). Yes, it will be obsolete in time. So will existing software solutions. If you don't want to use hardware cryptography, don't. If you don't want to use software cryptography, don't.
As far as tracking users goes, I can think of much better ways to construct evil programs and trojans to do this job much more effectively and doesn't require that the user have a motherboard with one of these chips. Privacy and security issues here are minimal at best.
The only thing this chip ever makes available would probably be your public key. The whole concept behind public/private key cryptography is to make the public key publicly available to those you want to communicate with.
If someone wants to write an evil privacy-invading trojan program that secretly tracks your every move, it's probably in their best interests to use any of the other ID mechanisms already on your machine, like the MAC address, Windows registration codes, e-mail addresses in your e-mail clients, etc., etc.
Besides, the article explicitely states that you'd need to enter a PIN/password of some form to use features of this chip. Now, I have no idea if it's possible to circumvent this, but you'd think IBM would have done a bit of thinking and planning prior to now, yes? *shrug*..
In short, the potential for privacy abuse is virtually nil, and it's comparitively zero when held up with other methods for identifying and tracking you that already exist in software and hardware. I don't see any virii, trojans or rogue software companies out there making use of that, do you?
Guys, if the digital signatures and encryption is done in a proprietary fashion, that will make it incompatible with everything out there that makes use of public/private key cryptography. Not exactly the road to public acceptance, if you ask me.
Though you're right -- the article is pretty vague, but surely they're using a cryptographic standard.
Question about reading chip ID's: Are these privileged or un-privileged operations?
What "ID's" are you talking about? Do you mean the public key? Does this really matter? The whole point about public/private key cryptography is to make the public key as widely known as you need it to be.
The article explicitely mentions you'd need a software-based PIN/password to access features of this chip, so I don't imagine these services will be available to any application unless you explicitely authorize it.
But only IBM, or their designated manufacturers, or people who send a signal to my computer to get my "digital signature", can get at my hardware, excluding me.
I'm confused. The only thing this chip does is provide encryption and digital signature services to applications. You will need a software-based PIN/password to access these features. I don't see how this allows IBM and its "evil" minions to "get at" your hardware. Am I missing something?
On another note. Isn't an embedded security device likely to go obsolete pretty rapidly? Then what, we have to buy a whole new motherboard instead of just installing the latest version of the software? That sucks.
All hardware-based cryptography products will be "obsolete" in short order. Does that mean they can be upgraded? Not without changes in US export laws.
It's certainly possible this chip is replaceable as cryptography improves in the future.
easy would it be to pry the sucker off?;) Or, I could just not buy an IBM. Yeah, that's the ticket.
Hey, suit yourself. It's just hardware-based encryption and digital signatures. The same sort of stuff I'm doing with PGP in software today. The only data that can be made public via this chip is your public key, which is something I make an *effort* to make public while I'm using PGP. I really don't see what all of the fuss is about. If you don't want to use it, just don't use it. If you feel like you don't want to buy from them, fine.
It's not possible to be 100% secure with your data. Period. It's all a matter of "degree". How "secure" do you want to be?
Sure, this solution is secure, but it's not *as* secure as other, unexportable alternatives. In ten years, "real security" will mean something entirely different. The original poster was using the term "real security" by saying the key sizes allowed by this chip were inadequate for truly sensitive data. I was simply saying that IBM is not marketing this mechanism for people that regularly make use of truly sensitive data.
Read the article if you haven't already. This is all discussed there.
Slashdot Mirror
That's what they did in The Net. If you look closely, most (all?) of the IP addresses used had one or more octets above 255, making it invalid. Pretty good idea, if you ask me.
Unless the spammer's "ISP" *is* the spammer, or the ISP is spam-friendly. At that point you have little choice but to go up another level. I've had to do that quite frequently.
Most people use IRC to chat with new folks, not to establish a "club room" where the same, select gang meets. It's kind of hard to meet a bunch of new people with similar interests on a server with such a small number of users, so they use a large, established one.
The whole hostname masquerading thing has been discussed on just about every IRC network. Those that choose to support it do so. Those that don't have their reasons.
The web equivalent of an IRC relay would be one of those anonymizer services. They could easily have chosen to use one of these if they were truly worried about their identity.
I'm amazed at how many posters on this thread are running on the "it's another CPU ID" gripe when that has no basis in reality.
It's because of the submitter's "summary" and "michael"'s subsequent editorial. It's obvious he didn't read the article. He just saw the "CPU ID" phrase and went ballistic, like so many uninformed privacy nuts that post here regularly.
I really wish the Slashdot authors would try to be a little less biased when it comes to the articles they post here. Slashdot has become MUCH too editorialized, which wouldn't necessarily be *all* that bad, except THEY DON'T DO A GOOD JOB EVEN AT THAT. They base their editorial comments and slurs on stupid/uninformed assumptions based on little/no information. As much as I love Slashdot, it will never be a true journalistic site until it can replace its poorer "authors."
I'm not sure I understand what you mean by "color range". The main thing to account for from an ergonomics standpoint is a) eyestrain due to the differing brightnesses of a monitor as compared to ambient room lighting; and b) different definitions of "white". Your brain tends to "adapt" to different lighting conditions, changing its own internal definition of "white" to match it as close as it can to the room's lighting. Having your monitor's "white" be a bluish color relative to your room light causes your eyes and brain to have to do a bit more work keeping colors sorted out. Plus, for those of us that do screen -> print work, color matching becomes a necessity.
I'm not sure how this affects the "color range" per se. It should affect color *correction*, sure. If you're worried about dropping your brightness/contrast too low for good gaming (where a bright color is meant to be seen as an "uncomfortably" bright light source), adjust your monitor. The brightness/contrast controls are meant to be easy to get at. *shrug*. Many games also have an internal "gamma" setting that could be used to compensate a for a monitor's conservative settings in this fashion.
The keys are stored in the hardware. The article states that in order to access these hardware features, you will have to provide a PIN to the software to gain access to the keys.
Without this manual step, it would become possible for malicious programs to digitally sign/encrypt things you didn't intend to sign/encrypt.
I will state that all things (this is stated liberally, I am sure that I am wrong in certain cases) that has to do with hardware can be discerned/extracted using software.
The reason private keys can't be "pried" from hardware products is because these hardware products provide no mechanism to retrieve the private keys.
It's the same reason you can't write a program to command an Intel CPU to change colors. The chip simply isn't capable of doing it.
When constructing something like a cryptographic chip, just build functions into the chip that you need. You don't want the private key to be exposed, so don't create a "return_private_key" opcode when designing the chip. There are probably things like "return_public_key", "encrypt_text_at_this_memory_address", etc. Unlike software, you can't just write a program to examine the details or inner workings of a piece of hardware. The hardware has to be explicitely programmed to volunteer that data.
Hardware data encryption has been something pushed for quite a while now. It's not that it's faster or more convenient than software solutions, and *certainly* it's not because the hardware is more adaptable. It's because the hardware version is incapable of allowing the private key to be discovered. Whenever you use software, the public and private keys are stored somewhere on the hard drive in a not-so-cryptographically-secure form. This means it can be found and stolen by a malicious program. That simply isn't possible with hardware solutions.
[I HATE the way posting seems to default to HTML now and strips out all the carriage returns.]
If you sign up for a Slashdot account, the default posting behavior is saved for you. We even have the ability nowadays to post anonymously via a checkbox...
Huh?
Do you have any idea how hardware based encryption products work? The whole reasoning behind hardware-based encryption is *because* it's not possible for software to retrieve the private keys! That's the whole purpose behind doing it. If private keys were somehow able to be retrieved, there'd be no point in doing it with hardware at all, because it has no advantage whatsoever over software solutions. This is a fundamental design requirement, and is EASY to assure.
I think you're being very rude here. The only reason I was saying 256 bits is plenty for me is because current encryption products use FAR LESS SECURE keys than what this chip is providing. I wasn't suggesting that you be a good boy and be content to use it. If you feel you have data that requires more security, USE A MORE SECURE PRODUCT.
The solution IBM provides should be the best possible. This isn't it.
A previous poster noted that this chip uses a 256-bit key for data encryption. A typical HTTPS/SSL connection uses a 40-bit key (with 128-bits implemented in "unexportable high-security" browsers).
I don't know about you, but this is more than adequate. IBM says as much and indicates if users need something more secure, they're free to augment this system with things like smart cards and the like.
If you're so concerned that people are getting a false sense of security with this device, you should be working to warn them about the dangers of secure web sites, which are significantly less "secure".
If you want to decrypt someone else's encrypted data nowadays, it's to your advantage to somehow gain access to their system and find a way to steal their private key instead of trying to "crack" it. By doing this in hardware, this becomes impossible. This is why hardware encryption schemes are so much more secure than equivalent software ones.
Hell, why not outlaw IP addresses while you're at it.
These things are necessary for networks to function.
As far as the hardware encryption chip goes, do a bit more reading and you'll discover that this really isn't something that *needs* to be disabled. The whole "it's another attempt to brand our computers with an ID" argument is just silly. The only thing that this chip does is hardware-based encryption/decryption of data, much like an MPEG decoder card. The only difference is that, for this chip to work, you'd want to publish the public encryption key so people can send you encrypted messages and you can send others encrypted/signed messages of your own. It's NO different than using a software-based encryption solution, except that with hardware, it's impossible for someone to "steal" your private key.
You assume that these encryption keys are associated with you personally. What you don't realize is that it's very common for secure HTTP sessions and SSH connections to generate new keys all the time.
So long as the remote end has *some* public key that represents your system, they can verify your messages and validate your signatures.
The difference between this hardware scheme and existing software schemes is that it's theoretically possible for a malicious program to obtain your private keys stored on your system. It's not possible to do this if these keys are stored in hardware.
First of all, why hardware? It's just as easy to implement the crypto in software. And software encryption can be much more flexible, handling larger key sizes for the ultra-paranoid, or forty-bit keys for the clueless.
The whole point behind using hardware crypto is that it's impossible for software to recover private keys that are stored in hardware. With software-based crypto, there's always the (small) chance a trojan/virus will discover and recover your private encryption keys.
Finally, why the hell would you do this when there was so much controversy over the PIII ID? I would figure that IBM has some good PR and advertising folks-- how did this one slip out the door?
Because this crypto chip has nothing to do with ID's. All it does is provide encryption and digital signing services. To use these services, you must provide a PIN to software, which enables the features. It becomes an explicit user-initiated process, not something that can be maliciously hidden in the background.
The whole point is to allow you to digitally sign and encrypt data. What's the point in building a hardware system if malicious code could digitally sign stuff on its own, without your approval?
It's rather commonplace for people to upgrade their desktop PC's every few years. CPU's change, motherboards change, hard drives change. To tie software to any of these components seems rather stupid to me.
The only reason this sort of thing worked with older mega-server architectures in the past is because those platforms didn't have the upgrade rate of today's PC's. Plus, even if an upgrade *was* performed, all you usually had to do was contact the software vendor and let them know. A new software key was re-issued in short order.
With the upgrade rates of today's systems, I can't imagine a software company volunteering to create a staff of people set up to handle the enormous volume of requests for new keys as people upgrade hardware.
This is *not* a "CPU ID" chip. It is designed to do hardware-based public/private key encryption. To use these hardware features, you must supply a PIN/password to enable access to your key pairs. Thus, it is an explicit user-initiated process.
To suggest that web site owners will start requiring people to use these keys is totally absurd. Why in the world would web site owners voluntarily reduce their client base to less than 1% of its current base (those that have machines with these chips)?
People are using the same arguments they used against the Intel PIII CPU ID thing, when really the two situations aren't alike at all.
If you don't want to use the encryption offered by the hardware, DON'T. Stick with PGP or whatever other software-based solution you're using today. The only difference is that in the hardware implementation, it becomes impossible for trojans/virii/malicious programs to steal your private PGP key.
What happens if your key gets compromised??
:(...
What makes you think this is possible? By storing the private key in hardware, it becomes impossible to access via software.
The only way the key could be discovered is by a cracking effort. At 256-bits (as one poster indicated for encryption, and 1024-bits for digital signatures), it's going to take a long time for that to happen.
How are you going to be able to communicate to the powers that be that your key has changed, and not only that, you could just change your key and all your new transmissions would be unreadable...
Uhh, the same way that people do it today with software encryption products (like PGP). Just pass out your new public key and stop using the old key pair.
Better yet, J. Smith over here invents a utility to reflash the chip with an arbitrary "identifier" and people can now pose as you
You assume that this chip can be "upgraded". It's quite likely that this chip is entirely hardware-based. No "flash" upgrade at all. That would leave it open to the attack you mentioned. The whole idea is to keep the chip completely isolated from software.
If you had read and understood the article, you would know:
By placing the private key in *hardware*, it no longer becomes accessible by software. It is impossible to recover a hardware-based private key via software.
The only way a hardware-based key can be discovered is if it's cracked. Seeing how distributed.net has been working on cracking the latest 64-bit RC5 key since the latter part of 1997, I don't think we have to worry about these hardware keys being cracked any time soon.
Dude, I don't know what sort of top secret information you're planning on distributing, but 256 bits is plenty for me. If this encryption is honestly inadequate for your needs, I'd seriously suggest that you lock your computer in a safe someplace and never ever connect it to any form of computer network. Hell, you might want to dip the hard drive into some molten lead and throw into the middle of the Atlantic if you're that worried.
HTTPS (SSL) predominantly uses 40-bit encryption. "High security" versions of the same thing run at 128-bits. The last I checked, the "default" PGP key length wasn't anywhere *near* 1024-bits, which this chip supports.
Again, it's all a matter of *degree*. True, there is software out there that uses key lengths a lot longer than what this chip offers, but you won't find that software in mainstream browsers and e-mail clients, which means it's useless to normal people.
Additionally, you seem to forget the whole purpose of moving encryption into hardware: It's impossible to recover the private key via software. Today it's theoretically possible for a trojan or other malicious programs to snoop around your hard drive, find your software-based PGP private key ring, and from there, somehow recover the private key. This is not possible with hardware-based encryption, hence its attractiveness.
Damn I feel like a broken record here..
the software can be used to track people wherever they go
A PIN/password is required to activate features of this encryption chip. Thus, encrypting or digitally signing something requires explicit user intervention.
There is no "ID" that is sent out by evil software. The only thing I can think of that might work in this fashion would be the public key, which is meant to be distributed anyway. If I were writing a trojan or an evil program to track users, I can think of a few better ways of doing this than relying on something only a small percentage of consumers is going to have available (like, say using the MAC address, Windows registration codes, e-mail addresses, etc., etc.)
I don't think you quite understand how this chip is supposed to work.
So everything made on a computer can be traced to that computer.
This isn't correct at all. The digital signing/encryption process requires the user to enter a PIN/password. The user must *explicitely* make the effort to digitally sign a document or to encrypt data. This isn't something that can just be hidden in the background for malicious or rogue software companies to take advantage of.
Though to be fair, it's certainly possible that this PIN requirement could be bypassed by a trojan/malicious coder. I'd be interested to hear how IBM plans to keep that from happening.
Furthermore, what happens when 128-bit keys are no longer secure enough and you need to move to 256-bit keys?
I believe a previous poster mentioned that this chip was capable of 256-bit encryption and digital signatures up to 1024-bits. Granted, it will be obsoleted in several years, but it's more than sufficient for items not of a super-sensitive nature. The article explicitely states that it should be adequate for around 80% of their customers. The remaining 20% apparently have needs for stronger encryption and either won't use this hardware chip, or will use it in conjunction with something else (as the article states).
Nobody's *requiring* this chip to be used. The whole idea is that the hardware chip completely hides the private key, making it impossible to recover by software (thus exposing data encrypted with it). Yes, it will be obsolete in time. So will existing software solutions. If you don't want to use hardware cryptography, don't. If you don't want to use software cryptography, don't.
As far as tracking users goes, I can think of much better ways to construct evil programs and trojans to do this job much more effectively and doesn't require that the user have a motherboard with one of these chips. Privacy and security issues here are minimal at best.
The only thing this chip ever makes available would probably be your public key. The whole concept behind public/private key cryptography is to make the public key publicly available to those you want to communicate with.
If someone wants to write an evil privacy-invading trojan program that secretly tracks your every move, it's probably in their best interests to use any of the other ID mechanisms already on your machine, like the MAC address, Windows registration codes, e-mail addresses in your e-mail clients, etc., etc.
Besides, the article explicitely states that you'd need to enter a PIN/password of some form to use features of this chip. Now, I have no idea if it's possible to circumvent this, but you'd think IBM would have done a bit of thinking and planning prior to now, yes? *shrug*..
In short, the potential for privacy abuse is virtually nil, and it's comparitively zero when held up with other methods for identifying and tracking you that already exist in software and hardware. I don't see any virii, trojans or rogue software companies out there making use of that, do you?
Guys, if the digital signatures and encryption is done in a proprietary fashion, that will make it incompatible with everything out there that makes use of public/private key cryptography. Not exactly the road to public acceptance, if you ask me.
Though you're right -- the article is pretty vague, but surely they're using a cryptographic standard.
Question about reading chip ID's: Are these
privileged or un-privileged operations?
What "ID's" are you talking about? Do you mean the public key? Does this really matter? The whole point about public/private key cryptography is to make the public key as widely known as you need it to be.
The article explicitely mentions you'd need a software-based PIN/password to access features of this chip, so I don't imagine these services will be available to any application unless you explicitely authorize it.
But only IBM, or their designated manufacturers, or people who send a signal to my computer to get my "digital signature", can get at my hardware, excluding me.
;) Or, I could just not buy an IBM. Yeah, that's the ticket.
I'm confused. The only thing this chip does is provide encryption and digital signature services to applications. You will need a software-based PIN/password to access these features. I don't see how this allows IBM and its "evil" minions to "get at" your hardware. Am I missing something?
On another note. Isn't an embedded security device likely to go obsolete pretty rapidly? Then what, we have to buy a whole new motherboard instead of just installing the latest version of the software? That sucks.
All hardware-based cryptography products will be "obsolete" in short order. Does that mean they can be upgraded? Not without changes in US export laws.
It's certainly possible this chip is replaceable as cryptography improves in the future.
easy would it be to pry the sucker off?
Hey, suit yourself. It's just hardware-based encryption and digital signatures. The same sort of stuff I'm doing with PGP in software today. The only data that can be made public via this chip is your public key, which is something I make an *effort* to make public while I'm using PGP. I really don't see what all of the fuss is about. If you don't want to use it, just don't use it. If you feel like you don't want to buy from them, fine.
It's not possible to be 100% secure with your data. Period. It's all a matter of "degree". How "secure" do you want to be?
Sure, this solution is secure, but it's not *as* secure as other, unexportable alternatives. In ten years, "real security" will mean something entirely different. The original poster was using the term "real security" by saying the key sizes allowed by this chip were inadequate for truly sensitive data. I was simply saying that IBM is not marketing this mechanism for people that regularly make use of truly sensitive data.
Read the article if you haven't already. This is all discussed there.