h a l f b a k e r yThese statements have not been evaluated by the Food and Drug Administration.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
One of the ways to get someone's password is to install a key logger on their system. These small programs simply record every key you press on the keyboard. They often go unnoticed.
I propose that, for work you need to do with security, you plug in a special USB secure keyboard. The program that
you are running then is told to take commands from the secure keyboard (you could mouse in a password to defeat any key logger already installed). The program would communicated with the keyboard with data encrypted.
I'm not saying that the communication between the program and the secure keyboard couldn't be hacked, but it would take a lot of extra effort to do so, and any program that would do it would probably be noticed.
All this is designed to do is to beat a simple keystroke logger.
About Keyloggers
http://www.safersit...bout_KeyLoggers.asp
[phoenix, Oct 04 2004]
[link]
|
| |
Pah. You'd need programs with the capability to store a (decrypting) key and decode the keyboard output. |
|
| |
[pheonix] I don't understand your critique (or is Pah a good word?). |
|
| |
If you're worried about stored keys, well, keys can be negotiated at first contact. That's how https works. |
|
| |
If you're worried about having a program have to do the secure communication, well, it's not that hard to program. |
|
| |
The idea is that this would be programmed into a program where security is absolutely necessary, such as a bank. Not for everyday stuff. |
|
| |
//You'd need programs with...//
This would be done by the keyboard device driver. |
|
| |
This would only stop hardware based keyloggers, a software based one (e.g. trojan horse) would still work. But it is an interesting idea, there might be a market for this in government agencies. |
|
| |
One improvement would be to allow end-to-end encryption for things like passwords. Make it so that when you select a password-protected field, the computer and keyboard do a special protocol negotiation so the computer doesn't know what characters were actually being typed. |
|
| |
"If you're worried about stored keys, well, keys can be negotiated at first contact."
Negotiated by whom? The OS and the keyboard? The application and the keyboard? |
|
| |
"This would be done by the keyboard device driver."
How do you think keypress loggers work? |
|
| |
Better would be a secure KM path that wouldn't work in the presence of keyboard loggers, either as software or the little hardware ones. |
|
| |
Of course, that requires a trusted core space in the OS of some type like, er, Palladium. |
|
| |
About hacking the USB keyboard -- I'm not saying it's not possible, I'm just saying it's difficult. |
|
| |
[phoenix] The keypress loggers work by monitoring the keyboard bus or IRQ or whatever. If you have a USB device, your keypress logger would be bypassed. You would have to specially design a keypress logger to monitor the USB communication and crack the encryption scheme. |
|
| |
I'm not saying it's not possible, but that program is a lot more complicated than the simple keystroke loggers that already exist. |
|
| |
[sealorator] There are some encryption schemes that cannot be hacked by the method you described. If both parties (the program and the keyboard) are using an encryption like the one used in SSH or SSL, you cannot crack the algorythm no matter how much sample data you get. Kindly remove your (-), or please show me how you hacked some SSL or SSH stream. ;) |
|
| |
"I could get past it easily..." <snerk> |
|
| |
//Of course, that requires a trusted core space in the OS of some type like, er, Palladium. // |
|
| |
Of course, the real purpose of Palladium is to make any vendor-approved snoopware undetectable. |
|
| |
// [phoenix] The keypress loggers work by monitoring the keyboard bus or IRQ or whatever. If you have a USB device, your keypress logger would be bypassed. You would have to specially design a keypress logger to monitor the USB communication and crack the encryption scheme.// |
|
| |
Not necessarily. Much easier would be to write an event handler to intercept the Windows event stream. |
|
| |
SSH is a pretty lightweight protocol. Just how much "system resource" is that going to take up? |
|
| |
What I'm actually asking is, are you making this up off the top of your head? Because it sounds like you are. |
|
| |
I wouldn't mind it if you hadn't given me the minus! ;) |
|
| |
//How do you think keypress loggers work?//
Well, there are two types... |
|
| |
There are software loggers, which you correctly surmise would not be fooled by encryption on the link. |
|
| |
But there are also _hardware_ keystroke loggers, that plug inline between the keyboard and the PC. These are impossible to detect or disable via software, and are thus very popular with law enforcement and corporate spies. |
|
| |
I was assuming we were talking about the latter type, but upon rereading the idea I see I was wrong. Hehe. |
|
| |
"Of course, the real purpose of Palladium is to make any vendor-approved snoopware undetectable." |
|
| |
Achieving security without a trusted core is going to be very, very hard. You've got to have something to anchor user identity and security upon before people and companies are going to allow their valuable digital assets on a machine. |
|
| |
//Achieving security without a trusted core is going to be very, very hard.// |
|
| |
Indeed, but it's much easier on a relatively spartan OS system runs on "bare" metal than on a system where it's impossible to tell what code is really running. |
|
| |
I agree that with a big codebase it is hard to know what to trust but, in some sense, their initiative with Palladium, or NGSCB, is trying to build a minimal "bare metal" space within the rest of the system within which the trusted seeds are sown. There has to be bedrock somewhere. |
|
| |
Typical users want a rich computing experience and so, I don't think many are interested in buying a spartan OS, but they might go for a place that can be spartan--and with a small hardened attack surface--inside their machine and upon which some trust can be placed by the users and their applications. |
|
| |
It doesn't change the applications but it does change what can be believed about what the applications are doing and allows new applications to be written that require trust as a vital element to their operation. |
|
| |
I don't know if the NGSCB approach is exactly the right one or not but I do think that something like it will have to exist for things to move on. |
|
| |
Ensuring a trusted keyboard/mouse path is just one aspect. |
|
| |
Can someone help me out? If the hardware in the keyboard is encrypting the keystroke sequences before it sends them out over USB, and the program talking with the USB keyboard is decrypting it in memory, how can this be hacked? |
|
| |
If you listen to the windows event stream, it seems to me all you would get was the encrypted stream. If you use the right protocols, this could not be reasonably decrypted before the universe ends. |
|
| |
It seems to me the only way to hack it was to fool the keyboard into talking directly to the hacking program, which then acts as the USB keyboard to the application which thinks
it's talking to the real keyboard. |
|
| |
Or, try to look at the decrypted keystroke sequence that the program keeps in memory. |
|
| |
My wireless Logitech USB keyboard does this nicely. You push a Reset button on the keyboard and the receiver to initiate setup. The software on the computer then shows you on the screen a series of characters that you have to type in at the keyboard. That's it. |
|
| |
The explanation I heard is that the keyboard generates the initial encryption key during setup. The keyboard driver on the computer learns this encryption key from the response it receives via wireless as the user types the characters on the screen that the driver generated during setup. |
|
| |
To break the key the villain would have to know what comes through the USB line and what is displayed on the screen. A keylogger listening to the USB would only read garbage. To get decrypted characters it would have to hook into the system after the keyboard driver. That's already pretty high up in the operating system and should be easy to detect (I guess, I'm not an expert at this). |
|
| |
"...how can this be hacked?"
Read my link. |
|
| |
[kbecker] That's only so your keypresses can't be intercepted by another receiver. It has nothing to do with keypress loggers working on the system. |
|
| |
But the system that [kbecker] suggested could be implemented just as well directly between some app and a keyboard designed to do it. The app just displays a series of characters needed to program the encryption key into the keyboard. Assuming a good enough encryption scheme is used (there's plenty of time to do decription when you're just dealling with keyboard input from a human), there are very few attacks possible. |
|
| |
One attack could be for the keylogger to intercept the mesage displaying the keystrokes to program the encryption key, and overwrite it on the screen with a different key, then intercept the keyboard strokes and reencrypt them with the key that the app tried to display to the screen. This could be mitigated by having the keystrokes to be typed displayed as a non-computer readable bitmap. However, if the keylogger software was designed to work with a particular application, there's nothing short of a Palladium-like system (like Bristolz said) that will prevent keystrokes being entered into a program from being logged. |
|
| |
Of course if your primary concern is just preventing a keylogger from caturing your password, and you're not as concerned about the actual content being typed, you could just log on using a smart card. |
|
| |
Um, I can't seem to find USB keyloggers, so if you have a USB keyboard, how is someone going to keylog it? PLEASE PLEASE PLEASE correct me if I'm wrong, because I would REALLY LIKE TO HAVE A USB KEYLOGGER, please point me in the direction of one. |
|
| |
You could use a PS2 adapter and PS2 keyboard logger. The system would notice the change though. Optimally the device would just be a USB extender and undetectable to the system. I can't seem to find such a device though. Find them, and secure USB keyboards will exist |
|
| |
I'm sure that with the co-operation of manufacturers and a few standards this could be accomplished. |
|
| |
At the moment, we have SSL certificates and a public/private key infrastructure to prevent, man-in-the-middle attacks. The only problem with trojans and keyloggers is that they can get the passwords before they're encrypted with the public key. |
|
| |
I was thinking that the keyboard would have a small LCD screen and a light/logo which lights up when a program requires secure entry. |
|
| |
The browser or application would need to send the signing certificate to the keyboard. The keyboard would have a directory of TTP certificates to guarentee that the signing certificate is legit and current. After the certificate is authenticated within the keyboard, the keyboard would then display the url: eg. www.bank.com in the LCD screen, and light up the "secure logo" light. |
|
| |
The user would be able to then type in the information required and the keyboard will be able to send back the encrypted key. |
|
| |
Because the SSL certificate system is being extended to the keyboard where no trojan can go, there is no way a trojan can stand in the middle because it can't decrypt a stream it has no private key for. |
|
| |
Of course this idea is getting very close to smart cards. Smart cards contain a computer chip which processes messages and returns encrypted values, not just a simple plain barcode. |
|
| |
In the end though, I'd like to see passwords, credit cards and my wallet dissapear forever, replaced by the finger print but that's another story. |
|
| |
I would like to see a keyboard with a "secure" mode to allow for entry of passwords. Among other things, it would provide some protection against an extremely simple but often effective social-engineering hack: a trojan with user-level access waits until the user does something that could be expected to possibly need the root-level password, and then puts up its own fake dialog box. Having an indicator on the keyboard which only the system software could control would help mitigate this threat. |
|
| |
BTW, I'm not a big fan of fingerprints. If someone's password is compromised, it may be changed. By contrast, once a fingerprint is compromised, what then? |
|
| |
An adaptation of this, which would actually work, is to have a secure keyboard contain a known encryption key shared with a remote service, such that it can be used to enter passphrases and secure commands with the client system never being aware of the contents. For example, you might store a key in such a device, plug it in as a second keyboard at a public terminal, and use it to enter your password when logging into your home system. |
|
| |