Prev: It's not science, it's sci.
Next: AES counter content and same key/nonce
From: JR on 3 Feb 2010 22:02

"Ilmari Karonen" <usenet2(a)vyznev.invalid> wrote in message
news:slrnhmirmj.vdj.usenet2(a)melkki.cs.helsinki.fi...
> On 2010-02-03, JR <p(a)pnp.com> wrote:
>>
>> - A person will phone up an admin at the central location with the
>> following information
>> - His employee Id
>> - The company he works for
>> - The number of hours he needs to use the resource for
>
>> - The admin needs to input this info to the tool & generate a token/
>> key which can be conveyed over the phone.
>> - The person will key in this token/key into a program running on
>> the machine at the remote location & he will get access to a resource
>> for that much amount of time
>> - The key shouldn't be too long - i.e. a 16 char key would be great,
>> anything longer may be problematic.
>
> I would use a truncated MAC for this. That is:
>
> - The employee tells the admin his company name, employee ID and the
> number of hours he needs.
> - The admin concatenates these to a single string S.
> - Using a secret key K known to the admin and the remote machine, but
> not to the employees, and some standard hash function, the admin
> calculates HMAC(K,S), truncates the result to, say, 32 bits, and
> tells that to the employee.
> - The employee keys in the same info they gave to the admin, plus the
> truncated MAC, into the machine, which repeats the MAC calculation
> and checks that the results match.

Thank you for your reply. The time thing is a problem.
The period (number of minutes) itself cannot be used as input because
the reservation should start as soon as the admin generates the key.
Using the period gives a problem that the user may enter in the key
after 1 hour or 2 hours, in which case his start time would differ from
the time the key was generated. The admin calculating the end time
& conveying it back over the phone to the user is also not good for
me. There may a be time zone difference. Also the requirement
is that the user just enter one thing at the machine - a license key kind
of string - nothing less, nothing more.
Is the encrypting the end-time in a way it can be recovered not possible
at within my key size constraints?



From: Greg Rose on 4 Feb 2010 01:25
In article <hkdcm2$l2m$1(a)news.eternal-september.org>, JR <p(a)pnp.com> wrote:
>
>"Kristian Gj�steen" <kristiag+news(a)math.ntnu.no> wrote in message
>news:hkbpae$kv4$1(a)orkan.itea.ntnu.no...
>> JR <p(a)pnp.com> wrote:
>>>I need to build a quick & dirty system for achieving the following
>>>[...]
>>>This is a quick & dirty solution I thought up for this. There is 1
>>>symmetric
>>>key shared between the central machine & all the remote machines.
>>
>> Use
>>
>> k = HMAC-SHA256(master-key, company)
>> token = truncated HMAC-SHA256(k, end time || employee id)
>>
>> The program deployed at the company has k and computes HMAC-SHA256(k,
>> end time || employee id) for various likely end times until it finds
>> one that matches.
>
>Thank you for your suggestion. However, the end time can be at 15 minute
>intervals
>& it could be quite long - i.e. they can reserve for say a week.
>So won't computing HMAC-SHA256 for all these times be rather time consuming?

7*24*4 = 672. So either the recipient can try up
to 672 hash calculations or the token can include
an extra two characters encoding the end time in
plain text to save the recipient some time...
either way, not a big deal.

Greg.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
From: Ilmari Karonen on 4 Feb 2010 06:57
On 2010-02-04, JR <p(a)pnp.com> wrote:
>
> Thank you for your reply. The time thing is a problem.
> The period (number of minutes) itself cannot be used as input because
> the reservation should start as soon as the admin generates the key.
> Using the period gives a problem that the user may enter in the key
> after 1 hour or 2 hours, in which case his start time would differ from
> the time the key was generated. The admin calculating the end time
> & conveying it back over the phone to the user is also not good for
> me. There may a be time zone difference. Also the requirement
> is that the user just enter one thing at the machine - a license key kind
> of string - nothing less, nothing more.
> Is the encrypting the end-time in a way it can be recovered not possible
> at within my key size constraints?

As Greg Rose suggested, you could encode the end time into the token
string together with the MAC. There's no need to actually encrypt it
-- it's not a secret, and the MAC will ensure that the employees can't
change it.

In your original post, you said the employee had to enter his/her
company name and employee ID into the machine together with the token;
now you seem to be saying they shouldn't have to enter anything but
the token. Anyway, in either case, you could do it like this:

1. The employee calls the admin, tells how long he/she needs the
machine and provides any other information needed to convince the
admin that the request is valid.

2. Admin takes the number of minutes since some base epoch, adds the
number of minutes of access time requested by the user, and denotes
this value by T.

3. Admin calculates M = MAC(K, T), where K is some secret key shared
by the admin and the machine (possibly different for each machine;
possibly derived from a machine ID I and some master key J known
only to the admin as K = MAC(J, I).)

3. Admin truncates M to, say, 20 bits _and_ T to, say, 10 bits (enough
to encode the maximum number of minutes an employee should be able
to request), concatenates the truncated values, encodes them in
some manner suitable for communicating over the phone and passes
them to the employee.

4. The employee enters the token given by the admin into the machine,
which splits it into the truncated versions of M and T (let's call
them M' and T' for clarity).

5. The machine reconstructs T from T' by taking the current number of
minutes since the epoch, replacing the 10 lowest bits by those from
T' and, if the result would be in the past, adding 2^10 minutes.

6. Using the reconstructed value of T, the machine recalculates M,
truncates it and compares the result with M'. If they match, the
employee will be allowed to use the machine until time T.

Note that M is calculated using the full value of T, not the truncated
value T'. This is what prevents someone from reusing the same token
again after 2^10 minutes, since the MAC check will fail then.

As specified above, M does not include information about the employee
or the company, which means that anyone who knows the token will be
able to use it until it expires. If you want to tie the token to a
given employee, this is possible with trivial modifications to steps 3
and 6: just let M = MAC(K, T || E), where || denotes concatenation and
E is a string identifying the employee.

Of course, this will still not prevent someone who knows both the
token _and_ the authorized employee's ID from just pretending to be
that employee. To prevent that, you'd need some way of authenticating
the employees to the machine, for example by a password or some kind
of physical authentication token.

The values of 10 and 20 bits above are just suggestions -- they should
be enough as long as nobody ever needs to reserve the machine for more
than 17 hours and as long as one in a million is sufficiently low odds
for a randomly guessed token to be valid. Feel free to increase them
if you want some more safety margin. You might also want to consider
making the machine lock up after, say, 100 failed authentication
attempts in a day, or imposing some minimum delay between attempts.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
From: JR on 3 Mar 2010 05:01

"Ilmari Karonen" <usenet2(a)vyznev.invalid> wrote in message
news:slrnhmldi4.eet.usenet2(a)melkki.cs.helsinki.fi...
> On 2010-02-04, JR <p(a)pnp.com> wrote:
>>
>> Thank you for your reply. The time thing is a problem.
>> The period (number of minutes) itself cannot be used as input because
>> the reservation should start as soon as the admin generates the key.
>> Using the period gives a problem that the user may enter in the key
>> after 1 hour or 2 hours, in which case his start time would differ from
>> the time the key was generated. The admin calculating the end time
>> & conveying it back over the phone to the user is also not good for
>> me. There may a be time zone difference. Also the requirement
>> is that the user just enter one thing at the machine - a license key kind
>> of string - nothing less, nothing more.
>> Is the encrypting the end-time in a way it can be recovered not possible
>> at within my key size constraints?
>
> As Greg Rose suggested, you could encode the end time into the token
> string together with the MAC. There's no need to actually encrypt it
> -- it's not a secret, and the MAC will ensure that the employees can't
> change it.
>
> In your original post, you said the employee had to enter his/her
> company name and employee ID into the machine together with the token;
> now you seem to be saying they shouldn't have to enter anything but
> the token. Anyway, in either case, you could do it like this:
>
> 1. The employee calls the admin, tells how long he/she needs the
> machine and provides any other information needed to convince the
> admin that the request is valid.
>
> 2. Admin takes the number of minutes since some base epoch, adds the
> number of minutes of access time requested by the user, and denotes
> this value by T.
>
> 3. Admin calculates M = MAC(K, T), where K is some secret key shared
> by the admin and the machine (possibly different for each machine;
> possibly derived from a machine ID I and some master key J known
> only to the admin as K = MAC(J, I).)
>
> 3. Admin truncates M to, say, 20 bits _and_ T to, say, 10 bits (enough
> to encode the maximum number of minutes an employee should be able
> to request), concatenates the truncated values, encodes them in
> some manner suitable for communicating over the phone and passes
> them to the employee.


Coming back to this rather old post.

I am going to be using something very similiar to what is suggested here.
So, thank you very much.

I just have one question.
Will truncating the MAC reduce the security of the whole thing?
i.e. I assume the MAC size depends on the size of shared secret key.
The bigger the shared secret key, the bigger the size of the MAC for one
particular size of the original message - am I right in this?
If I am right, will truncating the MAC compromise anything?
What I can do avoid the reduction in security? What should be the
size of the shared Key?


>
> 4. The employee enters the token given by the admin into the machine,
> which splits it into the truncated versions of M and T (let's call
> them M' and T' for clarity).
>
> 5. The machine reconstructs T from T' by taking the current number of
> minutes since the epoch, replacing the 10 lowest bits by those from
> T' and, if the result would be in the past, adding 2^10 minutes.
>
> 6. Using the reconstructed value of T, the machine recalculates M,
> truncates it and compares the result with M'. If they match, the
> employee will be allowed to use the machine until time T.
>
> Note that M is calculated using the full value of T, not the truncated
> value T'. This is what prevents someone from reusing the same token
> again after 2^10 minutes, since the MAC check will fail then.
>
> As specified above, M does not include information about the employee
> or the company, which means that anyone who knows the token will be
> able to use it until it expires. If you want to tie the token to a
> given employee, this is possible with trivial modifications to steps 3
> and 6: just let M = MAC(K, T || E), where || denotes concatenation and
> E is a string identifying the employee.
>
> Of course, this will still not prevent someone who knows both the
> token _and_ the authorized employee's ID from just pretending to be
> that employee. To prevent that, you'd need some way of authenticating
> the employees to the machine, for example by a password or some kind
> of physical authentication token.
>
> The values of 10 and 20 bits above are just suggestions -- they should
> be enough as long as nobody ever needs to reserve the machine for more
> than 17 hours and as long as one in a million is sufficiently low odds
> for a randomly guessed token to be valid. Feel free to increase them
> if you want some more safety margin. You might also want to consider
> making the machine lock up after, say, 100 failed authentication
> attempts in a day, or imposing some minimum delay between attempts.
>


From: Greg Rose on 3 Mar 2010 10:03
In article <hmlc1p$94o$1(a)news.eternal-september.org>, JR <p(a)pnp.com> wrote:
>
>"Ilmari Karonen" <usenet2(a)vyznev.invalid> wrote in message
>news:slrnhmldi4.eet.usenet2(a)melkki.cs.helsinki.fi...
>> On 2010-02-04, JR <p(a)pnp.com> wrote:
>>>
>>> Thank you for your reply. The time thing is a problem.
>>> The period (number of minutes) itself cannot be used as input because
>>> the reservation should start as soon as the admin generates the key.
>>> Using the period gives a problem that the user may enter in the key
>>> after 1 hour or 2 hours, in which case his start time would differ from
>>> the time the key was generated. The admin calculating the end time
>>> & conveying it back over the phone to the user is also not good for
>>> me. There may a be time zone difference. Also the requirement
>>> is that the user just enter one thing at the machine - a license key kind
>>> of string - nothing less, nothing more.
>>> Is the encrypting the end-time in a way it can be recovered not possible
>>> at within my key size constraints?
>>
>> As Greg Rose suggested, you could encode the end time into the token
>> string together with the MAC. There's no need to actually encrypt it
>> -- it's not a secret, and the MAC will ensure that the employees can't
>> change it.
>>
>> In your original post, you said the employee had to enter his/her
>> company name and employee ID into the machine together with the token;
>> now you seem to be saying they shouldn't have to enter anything but
>> the token. Anyway, in either case, you could do it like this:
>>
>> 1. The employee calls the admin, tells how long he/she needs the
>> machine and provides any other information needed to convince the
>> admin that the request is valid.
>>
>> 2. Admin takes the number of minutes since some base epoch, adds the
>> number of minutes of access time requested by the user, and denotes
>> this value by T.
>>
>> 3. Admin calculates M = MAC(K, T), where K is some secret key shared
>> by the admin and the machine (possibly different for each machine;
>> possibly derived from a machine ID I and some master key J known
>> only to the admin as K = MAC(J, I).)
>>
>> 3. Admin truncates M to, say, 20 bits _and_ T to, say, 10 bits (enough
>> to encode the maximum number of minutes an employee should be able
>> to request), concatenates the truncated values, encodes them in
>> some manner suitable for communicating over the phone and passes
>> them to the employee.
>
>
>Coming back to this rather old post.
>
>I am going to be using something very similiar to what is suggested here.
>So, thank you very much.
>
>I just have one question.
>Will truncating the MAC reduce the security of the whole thing?
>i.e. I assume the MAC size depends on the size of shared secret key.
>The bigger the shared secret key, the bigger the size of the MAC for one
>particular size of the original message - am I right in this?
>If I am right, will truncating the MAC compromise anything?
>What I can do avoid the reduction in security? What should be the
>size of the shared Key?

Truncating the MAC will obviously reduce the
security against forgery; this is unavoidable in
the scenario you have presented. However, you can
adopt a lesson from the bank teller machine. The
bad guy can't check whether the MAC is correct
himself; he has to ask someone else to check it
for him. Just ring alarm bells if anyone fails MAC
verification a few times in a short period. This
is like disabling or eating the ATM card if the
PIN fails three times in a row.

Greg.

>[...]
--
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: It's not science, it's sci.
Next: AES counter content and same key/nonce