2
$\begingroup$

In my application, I am trying to prevent counterfeit widgets from being used on our gadgets; think HP ink-cartridges. I will be doing such with UHF RFID tags embedded in the widgets.

Unfortunately, the environment in which the gadgets are used does not allow me to keep a database of every widget in existence. I am operating in a closed, non-connected environment. The gadgets will have a computer and RFID reader installed on them. And the widgets may be used across multiple gadgets and they are reusable for a certain, to be determined, number of cycles.

I'd like to use the unique Tag ID (TID) of each tag as the salt for a common passphrase. These will be used to generate a 32-bit hash which will then be used as the tag read/write enable field. I then want to use some other hash in the user memory as secondary assurance that the widget is indeed authentic. Possibly using some random number and/or the date/time. However, I'm not exactly sure how I'd do that across multiple gadgets without storing unencrypted, unhashed information on the tag.

I know my current plan is not fool-proof (and it won't be without a database), but I'd like to know if there's any other ways to make it stronger. The tags in question (Alien Higgs 3) do not have an onboard microcontroller or any other "smarts" with which to interpret data.

Improve this question
$\endgroup$
6
  • $\begingroup$ why can't i carve out the rfid chip and glue it to a fake widget? $\endgroup$
    – dandavis
    Commented Jun 21, 2016 at 9:29
  • $\begingroup$ You very well could. And it's something we've thought about. Not trying to make it foolproof, because we can't. Just trying to make it as difficult as possible to replicate. The hope is that the epoxy we use to hold the tags in place will be strong enough such that the tag breaks should they attempt to tamper with it. Also, the process in which the gadgets are used is very contaminant and microscopically sensitive, so any modification to the widgets may result in undesirable output from the gadgets. $\endgroup$
    – audiFanatic
    Commented Jun 21, 2016 at 10:10
  • $\begingroup$ without an on-board DB (bad idea; it could be breached) or online activation, you would have to validate the tid with a formula, like MS did for win95 keys: they were comprised of a main number that was evenly divisible by 7, which is how they validated w/o internet in 1995. Also, you can get sued in many places for trying to restrict refills... $\endgroup$
    – dandavis
    Commented Jun 21, 2016 at 18:11
  • $\begingroup$ @dandavis I was 3 when Win95 came out, so do you know where I can find some more detailed information on how that worked? With regards to being sued, A) this is something that came from higher up in the company and B) it's more an issue of intellectual property protection than restricting refills. Not trying to discredit your comment, it's just not something that's up to me; I'm just implementing it. $\endgroup$
    – audiFanatic
    Commented Jun 21, 2016 at 18:22
  • $\begingroup$ see a list of OEM win95 keys and look at the 2nd-to-last number of the various keys. for example 4287696 is divisible by 7 into an integer, but that's hard to guess/tell by looking. it's not a great system (they moved to online), but it stopped most of folks who tried making up a number... $\endgroup$
    – dandavis
    Commented Jun 21, 2016 at 18:34

1 Answer 1

Reset to default
2
$\begingroup$

First use the TID as input for a KDF to generate one or more tag specific keys, using a static, symmetric master key stored in the initialization software and gadget.

Use one of these keys to obtain access. Use another for verification of the tag.

During initialization derive and set the access key (s). Then create a HMAC over a static value (or multiple static values) within or outside the memory of the tag, and store it within the tag.

During read out by the gadget use the keys to gain access and to verify the HMAC value over the static value(s).

This symmetric solution can of course be complicated by several patches with regards to key management (roll over to different keys and such, possibly storing multiple hash values).

That's for a symmetric solution. If you're brave you may consider an asymmetric solution. As you don't have enough room for e.g. RSA signatures you may want to go for a small size signature. The obvious advantage is that you don't need to distribute the private key to the gadgets. These kind of schemes do however require more cryptographic capabilities from your side.

Don't forget to store a version number or something similar in your tags so you have an upgrade path.

Improve this answer
$\endgroup$
14
  • $\begingroup$ I appreciate the input and it does sound like what I need. But do you mind dumbing it down a bit for me? I do not come from a security background whatsoever, so a lot of this is new to me. I understand the first paragraph with the key derivation function (except what distinguishes a symmetric from asymmetric master key). My other concern is that the KDF uses a psuedo-random number to generate the keys. So how can I obtain access to the widget a second time after setting the tag's access password? Finally, given that the tag's password field is only 32-bits, what KDF would work? $\endgroup$
    – audiFanatic
    Commented Jun 20, 2016 at 19:00
  • $\begingroup$ (continued) I am planning on using Crypto++ library to provide me with a wealth of cryptographic functions. However, is there another you might suggest? $\endgroup$
    – audiFanatic
    Commented Jun 20, 2016 at 19:01
  • $\begingroup$ About the KDF's: A KDF doesn't require you to use a pseudo random number to generate the keys. It just needs a master key and input. For some you may use a salt, but that's optional. Furhtermore, KDF's generally have a configurable output size. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 20, 2016 at 19:03
  • $\begingroup$ So in my case I wouldn't be using the TID as a salt, per-sey, but rather as input along with a master key? What's the distinction between a salt and input? $\endgroup$
    – audiFanatic
    Commented Jun 20, 2016 at 19:05
  • $\begingroup$ You'll have to look up the difference between symmetric and asymmetric cryptosystems yourself. If you don't get that distinction you may not want to implement this. Crypto++ is a well used crypto library. I can only advice you that that's a good thing, not much more. Botan is another; I don't particularly like either design, but then again, I don't particularly like C++ either. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 20, 2016 at 19:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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