Bruce Schneier

 
 

Schneier on Security

A blog covering security and security technology.

« Forensic Printer Codes May Be Illegal in Europe | Main | Research on Malware Distribution »

February 25, 2008

The Doghouse: Drecom

They advertise 128-bit AES encryption, but they use XOR.

This is why evaluating security products is hard: the devil is in the details.

Posted on February 25, 2008 at 01:32 PM25 CommentsView Blog Reactions

To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.

Comments

Hi,

More snake oil for the gullible. As long as there are people who buy such stuff, there will be people who will sell them such crap. The cycle repeats ...
Cheers.

Posted by: Anon Indian Techie at February 25, 2008 02:04 PM


caveat emptor

the more things change, the more they stay the same...


Posted by: crac at February 25, 2008 02:15 PM


"Upgraded for Performance Reasons"

Posted by: Patrick Cahalan at February 25, 2008 02:59 PM


Innmax (The controller's manufacturer) is the one who was outright deceitful, as far as I can tell. Drecom was a little over-credulous, but if I was manufacturing a chip that used two different encryption algorithms for two different things it did, I would go out of my way to make it crystal clear what was going on, and it sounds like Innmax was...less than clear.

Posted by: Erik at February 25, 2008 03:03 PM


Reminds me of the software "encryption" offered on my Western Digital USB drive. After "encrypting" most of my files, I realized that I could zip them up in half. If you can do that, the files are not encrypted.

Posted by: WD Sucker at February 25, 2008 03:14 PM


"Anon Indian Techie", this isn't snake oil. Such a product as was advertised is completely feasible and secure if properly implemented. No red flags such as inflated or unrealistic claims that a security expert could spot. With any such product (and there are lots) we are trusting the manufacturer to engineer the product to back up the advertising.

Posted by: Observer at February 25, 2008 03:30 PM


@Observer - failing to implement a product to the advertised spec sounds like Snake Oil to me. In fact it sounds like Bait and Switch and several other choice phrases too.

If what I've read is correct, Innmax should be sued!

Posted by: DavidG at February 25, 2008 04:01 PM


I can almost hear the faint, ghostly laughter of Alan Turing and his colleagues at Bletchley Park.

Posted by: David Harper at February 25, 2008 04:10 PM


Drec(k)om?

I mean, Yiddish isn't that far from modern German, no? Didn't this occur to them? Or maaaaayybe not!

Posted by: Paul Renault at February 25, 2008 04:37 PM


@Paul Renault

No, that did not occur to them, Dude.

Posted by: Brandt at February 25, 2008 05:47 PM


Now what happens if you are a coder at someplace that wants to use this, your debt will not allow failure and the progenitor nephew has told his ( ommitted to avoid starting firefights ) that this is easy. I notice three characteristic of these sites that do this.

1. Fancy website editor. Not an issue of it's own but correlatable in the broader overview.

2. Wholesome female, that is proven in marketing + in this paticular case the eyes are used to draw the viewer to the peel-label stickum which conveys approval ~ a common tool used to get past review.

3. Overall sense of easyness.

None of these issues will stand critical review individually, but they will appeal to uninformed JellyBabies. Of more interest would be how to defeat an intrusion by this in a client campus. Possibly there are telltales in the traffic.

Posted by: Nicholas Jordan at February 25, 2008 06:14 PM


It sounds like Innmax is guilty of false advertising if Drecom's claim of the spec being misleading, is true. It probably is true. On the other hand, Drecom has an incentive to overstate how misleading the spec was, in order to divert blame from themselves. I haven't seen the spec and can't judge it.

However, spec or no spec, Drecom had some responsibility to *look* at the output of the chip, in much the way the authors of the linked article did, to verify its security before mass-producing a product based on it. The fact that they apparently didn't notice the chip was insecure shows some negligence on Drecom's side, independent of the deceptive spec.

Posted by: Matthew Skala at February 25, 2008 06:22 PM


@paul & Brant - sorry please let me in on it. I known almost no yiddish and couldn't find anything that could translate that.

Posted by: DavidG at February 25, 2008 06:29 PM


Now that IS funny!

(I didn't try the root)

Posted by: DavidG at February 25, 2008 07:07 PM


Without further details of the crypto analysis, it could still be encrypted but with the same key and initializing vector for each sector. My first attempt at on the fly disk encryption on a CP/M system 35 years ago had the same failing. Second attempt was much better ;-)

Posted by: igloo at February 25, 2008 08:35 PM


This "The IN7206 merely uses AES encryption when saving the RFID chip's ID in the controller's flash memory" appears to attempt to prevent determining the RFID from the drive. In the case of the corrected IN8202 chip, would we have any expectation the RFID tag would be a short range chip? One can find reference to a long range RFID chip receiver (450 feet) for asset control. How about an iButton instead?

Posted by: DioGratia at February 25, 2008 08:49 PM


--The company claims the IM7206 only offers basic protection and is designed for "general purpose" users.--

Well, if it's for general purpose why do they use encryption in the first place?

I think they have to admit that they don't understand anything about security nor on how encryption works.

Posted by: Ronald van den Heetkamp at February 25, 2008 09:29 PM


I'm not wanting to justify the dismal security of this product, but it's perfectly possible that they are using AES, in counter mode, and simply failing to adjust the IV on each block.

Posted by: Nicko at February 26, 2008 01:19 AM


"using AES, in counter mode, and simply failing to adjust the IV on each block"

I don't think that you could call it *counter* mode in this case...

Posted by: Anonymous at February 26, 2008 03:10 AM


"This is why evaluating security products is hard:"

No, it is quite easy in this case: Just look at their website.
- table layout
- small white fond on black background (they don't want me to read it)
- to follow the link to "Produktdaten" you must enable Javascript (they emulate html-hyperlinks by Javascript).

I would never trust a "security company" that forces me to run untrusted programms, just to look at the product specifications.
The product probably will be scrap, just like their website.

Werner

Posted by: Werner Baumann at February 26, 2008 04:41 AM


Since nobody did it yet, here's the link to the 'security' chip page in Innmax:
http://www.innmax.com/en/im7206.html
Not a hint of the actual algorithm used...and they boldly advertise AES 128 bits

Posted by: newbrain at February 26, 2008 08:48 AM


I find this page outright misleading:

http://www.innmax.com/en/im7206.html

Posted by: Shevek at February 27, 2008 03:13 AM


@The product probably will be scrap, just like their website.

Correct, and the consumer who cannot figure that out can probably be protected by what they are doing and for those who need decent protection I don't see where placing on a cell deviece something that actually needs 128 bit AES makes any sense. If you need something that strong you should probably pack a custom board in a 1510 and dress like any high-profile target would.

Customer: I need reservations to Cuttham, Burnham & Runn on the River of Gold.

Ticket vendor: Did you want a turbo-charger on your Mercedes ?

Posted by: Nicholas Jordan at March 5, 2008 01:56 PM


Post a comment



Real names aren't required, but please give us something to call you. Conversations among several people called "Anonymous" get too confusing.



E-mail is optional and will not be displayed on the site.


Remember Me?


Powered by Movable Type 3.2. Photo at top by Steve Woit.

Schneier.com is a personal website. Opinions expressed are not necessarily those of BT Counterpane.

 
Bruce Schneier