9

Suppose I have a (bluetooth/usb) device which needs to displays information on an external pc/phone. Is there a simple and effective method to garantuee that the information displayed hasn't been altered by malware on that PC or phone?

One possible solution I thought of: the device could generate an unique picture once (based on a private key), and draw the information text on that image every time, and send the end-result to the smartphone. Now if the attacker wants to change the text, it will create gaps in the image, and the attacker cannot fill the gaps, because he doesnt have access to the original background picture, which is stored on the trusted device. As long as the end-user recognizes the image, and visually inspects it very careful for artifacts, that could be pretty secure?

Is there a better solution than the one I just proposed?

  • 1
    What exactly are you asking? Are you trying to ensure integrity of information from source to destination? Or are you just worried about the final step using Bluetooth? – Rory Alsop Dec 25 '13 at 19:10
  • 2
    I don't understand the threat model here, what is wrong with the bluetooth pairing system? – rook Dec 25 '13 at 19:18
  • How about processing displaying part with some trusted processing (e.g. TEE) on the untrusted device? If there is untrusted software running on untrusted device, it can be as broken phone as it wishes. In fact, it can even act maliciously or try to deceive. – user4982 Jan 4 '14 at 11:18
  • @user4982 Do you have some link/source that explains it? – Muis Jan 4 '14 at 15:43
  • @Muis: TEE=Trusted Execution Environment. ARM has security technology on their chips they usually call TrustZone. Some sort of TEE is implemented on top of TrustZone. Some of the smartphones (especially high-end ones) leverage that technology to provide better protection for their system and most important secrets. TEE is not concept for ARM only, but given the current consumer interest on ARM-based smart phones and tablets, there are quite a few TEE solutions for ARM-based platforms available. – user4982 Jan 4 '14 at 16:14
2
+100

The idea of using background that is recognizable is pretty good one. However, T. Pornin has been kind enough to point out some issues with that approach.

Short: Use MobiCore or other TrustZone implementations where available. For untrusted devices without TEE, currently you need to use Rich OS only. In future, maybe more devices offer TEE.


Issues with trust and confirmation

Ultimately, the issue is: if you cannot trust components and software executing on the device you cannot trust the device to not change the confirmation message/button shown to the user.

There is no perfect solution for this problem (asking confirmation on untrusted device). This is a widely known fact. There are even occasionally issues with devices generally regarded as "trusted" (e.g. ATM). So, banking and credit business is always expecting some amount of fraud and prepared to deal with it.

Untrusted devices

For many applications, currently it is regarded to be secure enough having applications running directly on untrusted mobile devices. (Such as online banking etc.)

Trusted Execution Environment

What if it was possible to have trusted environment for use cases needing extra trust? (For use cases mobile commerce, BYOD, etc.)

Network operators and hardware manufacturers formalized much of requirements for Trusted Execution Environment useful for running "trusted software" in trusted environment on device which non-trusted OS (also known as HLOS, Rich OS, General Purpose OS, or Normal World OS). These documents are OMTP TR0 and OMTP TR1. They are one of best presentations of usual requirements for TEE.

TrustZone

ARM+Trusted Logic started working on this idea around ten years ago. ARM processors got TrustZone, which has been there since. Although largely good idea in practice, big issue was: there is support on hardware, but software solutions did get it utilized all that much, until recently.

Technically, it is possible to consider TrustZone as limited HW support for virtualization, with intention to use one rich OS and one secure OS.

G&D MobiCore has been one of few implementations that have gotten to major mobile phones, it is available on Samsung S3, S4. Samsung Note III has Samsung Knox. I think it also is based on MobiCore on TrustZone.

Some other phones have some other software. In many cases, there are no details available of what phones do with software they could or do load on TrustZone, which is available on almost all current smart phones.

To get proper SW support for TrustZone, G&D, ARM and Trusted Logic Mobility together founded Trustonic, which is making the next generation Trusted OS

16

I understand your question as follows: there is a tangible device which may produce data and send it over radio (Bluetooth); and another device (say, a smartphone) which receives said data, and displays it; the problem being that the second device cannot be trusted. So the question is: can we do something about it, so that we may gain some confidence in the data as displayed being a faithful representation as what the first device sent ?

Generically speaking, no, we cannot; liars lie. Unless the data that the first device sends comes with some sort of checksum or signature that the second device cannot forge or fake (digital signatures and MAC might prove useful cryptographic tools for that), and that the human observer verifies independently of the untrusted smartphone. This latter point is the true problem: a normal human observer will not compute in his head a signature verification or a MAC.

Workarounds for that kind of situation come in two kinds:

  • Add a display directly on the first device, so that the device may display its data directly, without interaction from the potentially hostile smartphone. This is what is done with payment terminals: though they are linked with a cash register which is, basically, a PC, such terminals still have their own screen and keyboard because the cash register is not ultimately trusted.

  • Add a third device to the dance. Give the user a device that he trusts, and that will verify whatever MAC or signature computed by the first device. Mutatis mutandi, this is the Internet, with the untrusted smartphone mapping to mere routers; some SSL between source and destination protects the integrity (and confidentiality) of data from mishandling by routers.

(We may note that this problem is also an inherent issue with smart cards inserted in PC through dedicated readers or USB ports. When we enter the PIN code, it is on the PC; we cannot really know what the PC asks the smart card to sign.)

  • 2
    Your picture-based proposal relies on the existence of a picture that the human user knows of, but nobody else (in particular, not the attacker would hijacked the smartphone). This seems hardly realistic; moreover, inspections of a few such pictures-with-text will reveal most original picture pixels, so this is a one-shot security feature. Finally, your proposal also requires that any text alteration would result in gaps, which is not guaranteed (e.g. turning a 'P' into an 'R' needs only extra pixels). – Thomas Pornin Dec 26 '13 at 16:39
  • The picture could be auto-generated (like gravatar.com generates avatars) on the device itself, so how could an attacker get hold of a full copy without root-access to the trusted device? But you are right that once an attacker has hundreds of inspections, he should be able to deduce the original by combining the parts. So yes, its not foolproof, but I cant think of anything better. I hoped someone else could. – Muis Dec 27 '13 at 13:41
  • The only thing I can think of a recognizable image being useful for, is if you have a authentication process of some sort and you want the end user to distinguish that it is indeed their account before even being logged in. Which I would think would come in handy when you have multiple users using the same device.This is not the case though, the image would do virtually nothing to ensure the integrity of pointa->pointb. – user20624 Dec 30 '13 at 23:43
1

The scheme for overlaying text on a known image is clever, but not secure. It does nothing to prevent an attacker from adding content (think adding zeroes to the end of a number - this could be detrimental). Furthermore, you are depending on the secrecy of the source image and human ability to distinguish parts that have been 'filled in', which is risky.

The best solution would be to just display the message normally along with an HMAC, and then transcribe the whole message with the HMAC to another device for verification.

If no other device is available, what you would need is a digital signature that can be verified by a human, but cannot be changed by a computer without the person noticing. Such a thing does not yet exist. However, something like the following could theoretically work, though it would be really cumbersome and would not be secure against tampering by a human:

  1. Create a security word that the secure device and human both know.
  2. Append the security word to the end of the message.
  3. Come up with a manually-verifiable checksum algorithm and compute the checksum of the message. (This checksum need not be cryptographically secure, so something like CRC32 that is modified to make manual computation easier would be okay.)
  4. Append the checksum to the end of the message
  5. Write out the whole message using a CAPTCHA library so that a computer cannot read any of it.

Any tampering with the message would break the checksum, and wholesale replacement would remove the security word. The security word could be copied, but since a computer cannot read the word, it would not be possible to compute a correct checksum on a message that includes it. If you wanted to protect against repetition and reordering of messages, you could also add a nonce (a monotonically increasing message counter would do). If you care about freshness you could add a timestamp (before applying the checksum, of course).

Warning: The success of this hairbrained scheme relies not only on the security of CAPTCHAs (which have been successfully attacked many times), but on the user being able to read the entire message without making errors. Given that the human error rates on single-word CAPTCHAs are non-trivial, this could lead to quite a low verification success rate, which would cause frustration. The same message could be written multiple times to decrease the human error rate, but this would also make it easier for a computer to break the CAPTCHA.

  • I think the hardest part would be to come up with the manually computable checksum, because most checksum algoritms depend on lots of iterations, and thats something the human brain is bad at, and will require lots of time. – Muis Jan 4 '14 at 9:51
  • Some sort of "checksum" is the only theoretical way to verify the integrity of a message you have never seen before. However, a checksum doesn't have to be an iterative algorithm; it could be something as simple as repeating each word 1-5 times, and then listing the number of repetitions at the end. E.g.: "this this is is is is a a a message message message 2 4 3 3". This bloats the message a lot more than CRC32, but is easier to manually verify. – Kevin Borders Jan 4 '14 at 17:00
1

The others have already covered the technical detail. To answer your question directly though from basic principles:

"[After something is transferred by bluetooth.] Is there a simple and effective method to garantuee that the information displayed hasn't been altered by malware on that receiving PC or phone?"

The answer is no, you can't.

Your scheme is clever, but fundamentally, if the pc or phone is compromised it can never be trusted. In the case of banking malware we see them go as far as to 'emulate' correct behaviour but actually do something else. In the case of your scheme it could keep an untainted copy of whatever is transferred and even render your picture using that, but whatever the important thing was I assume you do after this will be compromised with a second set of altered, malicious data.

0

As others already pointed out, you cannot trust anything an untrusted device tells or shows. You need a trusted interface for that, or some verification mechanism as you tried to create, but I’m afraid repairing a background is just too easy for that. I wouldn’t want something like a photographer’s watermark to be all that stands between me and sending thousands of € to someone else’s bank account.

There is a solution that is in use (at least) in Germany for online banking, called ChipTAN: The untrusted device displays a graphical representation (you could use QR, ChipTAN uses an animation with five flickering bars, because the reader is much cheaper to build) and have some trusted device (here, a small reader box with five photosensors and a display that connects to you bank card’s chip) read and display that information. ChipTAN devices then let you create a transaction authorization number tied to the information you just saw.

  • I was trying to get rid of the display on the device, and ChipTAN still needs a display. – Muis Jan 4 '14 at 9:47
  • If your trusted device can read exactly what you read (OCR A?), it could just have a single LED for “signature verification successful”. But that is only useful for fixed-format messages where you can be certain the device reads exactly what you think it reads and does not, e.g., skip characters which you didn’t realize where unreadable to the device. – Christopher Creutzig Jan 4 '14 at 12:35
0

Are you afraid that the message will accidentally be lost and go unviewed? Are you afraid that the message will be modified, telling someone they only spent $10 when they really spent $10,000? Or are you afraid that the malware will act reliably on any amount under $1,000, but suddenly stop demanding confirmation if the bad guy transfers $10,000? If that's the case, maybe your server side needs to not deal with untrustworthy devices when your risk exceeds a certain threshold. For example, you could require two-factor authentication for amounts over $1,000, so you're not completely trusting the phone for every transaction. Set your limits based on how much you trust (or don't trust) the phone devices.

And things that can't be controlled with technological solutions can often at least be addressed with audits.

The user could occasionally (and randomly) validate the information on the display is actually what the server sent. They can do this in several different ways: they can physically go to the server and look at its native display; they can use a second device (perhaps a different model phone provided by a different vendor); they can connect to the server via web browser and doublecheck that way; or they can go back later and check the server's logs. Or the server could occasionally send the information two ways, using side channels such as SMS or email to provide confirmation.

If a user checks one out of every four messages, the untrustworthy device stands a 25% chance of getting caught every time it presents a phony message. If you're the bad guy in control of the untrustworthy device, those are really bad odds for being able to cause long term damage to the messages without getting caught. (This requires the user to be random in their audit checks: re-checking every time the last digit is zero represents a pattern the attacker could exploit.)

Of course as with any solution involving fragile people, the problem is diligence. If a system proves reliable for the first month, most people will stop checking it after two months. That's human nature. Two factor authentication in high risk situations helps solve that problem.

  • The device signs Bitcoin transactions, so I was looking for a way to have only a confirmation button on the device, but no screen. – Muis Jan 4 '14 at 9:45
  • What you need is to display something the device and the owner would both know, but the phone would have no way of recognizing or figuring out. (It could figure out your picture scheme and modify it.) – John Deters Jan 4 '14 at 21:49
  • The problem with just displaying some image the device and owner both know, its easy for malware to leave that image intact, but only modify the transaction details alongside the image. Thats why I had the idea of combining them into one. If you read my idea carefully, you would see there is no way for the phone to figure out that scheme. – Muis Jan 4 '14 at 22:43
0

You could think about a small display on the device which shows the most critical information (for example a caller-ID, fingerprint or amount - depending on the use case). In some other situations you can use something hard to forge like for example there are crypto headsets which do a voice "verified" fingerprinting.

And what you can also do is to use a QR code so a sensitive user can see and validate a digital signature on a trusted (but limited) personal device and still use the untrusted bigger device to do normal processing (think printing internet cafe).

  • 1
    Im trying to find a solution to get rid of the display on the device. – Muis Jan 4 '14 at 9:43
0

The main problem is, once your single communication channel is compromised, anything that comes out of it is suspect. You're hoping the end point is able to detect, recover from the issue. In addition, once the end point itself is compromised, then traffic compromise is moot. Though end point compromise is something that shouldn't be attempted, because there's a real chance of getting caught. Which is why OTP token based solutions involve out of band calculations of the token.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.