System for securely authenticating content acquisition

Question

I'm having trouble designing a system for authenticated content from my site distributed by other people. I'm working in Ruby on Rails, but I don't think that at a theoretical level my question isn't restricted to that framework. In order to not give too much away, my site (let's call it www.site.com) helps businesses keep inventory of who has purchased what item, and allows customers to view their purchase history.

Hence, I have the following problem:

1. Suppose Alice sells cheeseburgers. Alice makes an account on site.com and registers her cheeseburgers as an item that she sells. Consequently, site.com stores Alice's cheeseburger in a SQL database with the id 92314
2. Bob is a customer at Alice's cheeseburger stand and has recently purchased a cheeseburger.
3. Alice would like to tell Bob about site.com and its ability to track purchases. Hence, Alice sends a request to site.com to return hashA that corresponds to item with id 92314.
4. Bob visits www.site.com/purchase/hashA and is prompted to either create an account or sign in to log his new cheeseburger purchase from Alice's Delicious and Delectable cheeseburgers.
5. Charlie also visits Alice's cheeseburger stand and purchases a cheeseburger.
6. Alice would also like to tell Charlie about site.com and sends a request that generates hashB for Charlie to use in the same manner.

My question is, how do I come up with a scheme that can generate hashA and hashB in a way that my web server can efficiently lookup the items. I suspect that hashB can be generated from hashA using some sort cipher using hashA as a seed. I don't know how, upon receiving hashA or hashB, site.com will know that it corresponds to item 92314. I suspect that using a nonce will help.

Things that I would like to avoid include:

• Having Charlie use hashA after it has been used by Bob
• Exposing the id 92314 to the user
• Having a single point of failure (i.e. a single key that encrypts hashes for all ids)
• Having things break if Charlie uses hashB before Bob uses hashA.

Disclaimer: My expertise is more in computer graphics and less in web development or cryptography, so pointing me towards things to Google is helpful. If this belongs in any of the other stackexchange sites (Cryptography, Programmers, etc). Feel free to let me know and I will move it.

Answer 1

If I understand your problem correctly:

• Alice is authenticated with the Server. When Alice talks to the Server, the Server knows that it is Alice.
• Alice has an "item" on the Server corresponding to some ID in the database.
• Alice may grant some sort of access to the item, to persons of her choice, e.g. Bob and Charlie.
• Bob and Charlie will connect to the Server afterwards, using a token that was sent to them by Alice, and which represents the access right on the server.
• The ID must not be revealed to anyone outside of the server. Tokens for Bob and Charlie must be distinct from each other, and not be guessable.

So this points to this generic solution:

• When Alice obtains a new token T from the Server, the Server remembers that "the token value T is for item 92314". This memory is, say, a new row in a dedicated database table.
• Each time Alice requests a new token T, the Server generates one randomly. If the token values are large enough (16 bytes or more), then probability that the Server generates twice the same token value is negligible. Alternatively, since the Server remembers all produced tokens, it can enforce unicity.
• Optionally, the token T may be time-limited (the Server forgets emitted tokens after some time) and/or one-shot (the Server forgets emitted tokens after usage).
• Optionally, when Alice obtains a token T, she may tell to the server "this is for Bob" so that when Bob connects, parts of the registration form are already filled.

With a time limit, the number of tokens to remember, with their association to the item ID and optional user information, can remain bounded, and thus be technologically manageable.

An optimization is to offload this memory onto Bob. This means that the server will encode into the token value itself whatever it would have liked to remember. In that sense, memory is free. However, this requires cryptography, because:

• It should not be feasible for outsiders to generate token values that the Server will accept; token generation should be a Server monopoly. This points to the need for a MAC.

• The token contents, that the Server wants to remember, are confidential. So encryption is needed as well.

In both cases, there are keys, and that's unavoidable: keys are knowledge, and in cryptography, knowledge is power. Everybody can buy the same computers, so if the Server can generate token values and other people cannot, then the Server must know something that the other people do not. That "something" is what cryptographers call a key. Cryptography can help you concentrate that "knowledge" into a very small, non mutating value, say a sequence of 128 bits (16 bytes). But it cannot make it disappear altogether.

The scheme for this "memory-less" Server is then:

• Given data D, token value T is the encryption+MAC of D. In order to make tokens for Bob and Charlie distinct, D may contain a global counter, the date of production, and/or some random bytes. D will also contain the item ID, and everything that the Server wants to "remember" about this token.

• When receiving a token T, the Server checks the MAC and decrypts it, obtaining D, thus everything that is need for registering Bob (or Charlie).

• Optionally, when Bob's account is created, the token value T used by Bob is recorded in Bob's account. Thus, when a token T' is received, the Server can check whether T' has not already been used to create an account. This is to prevent Bob himself from giving copies of his token to his friends. This implements a "one-shot" property for the token.

Combining encryption and MAC properly is a matter of subtlety. If you do this road, you are encouraged to use an encryption mode which does both the encryption and the MAC in the cryptographically correct way; i.e. GCM or EAX.

Answer 2

Whoa! You're overcomplicating the issue to a high degree; the matter at hand is way simpler.

Table 1 (products)

product_id - product_name - product_key

product_key can simply be the sha1() of product_id, product_name, and some random bytes. Or, better, just grab random 16 bytes and pass them to sha1().

Table 2 (requests/invitations)

request_id - product_id - request_key - valid

request_key is generated the same way: the sha1() product of request_id, product_id, and some random bytes. Or, simply, the sha1() of some 16 random bytes.

Now, when Alice wants to tell Bob about site.com, a row in "Table 2" will be generated, and she'll simply send him the link site.com/purchase/request_key.

Same thing happens when telling Charlie; a new row in "Table 2" will be generated (new request_key), thus, a new link. Once the link is visited, you check if valid is true. When the key is used, you set valid to false.

• The key can only be used once.
• The ID isn't exposed.
• No fancy encryption.
• Each request key is independent.