Account deactivation and public key validity

According to RFC8555 it is possible to deactivate an account. The effect is that any subsequent POST or POST-as-GET with this key pair will result in an unauthorized error (status code 401).

What is not specified in the RFC is the result of a subsequent new account request with the same public key. Will it be rejected as unauthorized, or will it be considered as a new fresh account ?

In the former case, this would allow to bloc any other user to use that same public key. It is unlikely, but could happen in theory. This would also imply that when an attempt to get a new account fails with the unauthorized error, we should generate a new account key.

1 Like

New account requests are also POST requests, so you get an unauthorized error as well, when using a deactivated account key:

Relevant excerpts from RFC 8555:

...If a server receives a POST or POST-as-GET from a
deactivated account, it MUST return an error response with status
code 401 (Unauthorized) and type
"urn:ietf:params:acme:error:unauthorized"...

...Once an account is deactivated, the server MUST NOT accept further
requests authorized by that account's key...

...ACME does not provide a way to reactivate a
deactivated account...

This could only happen if two users coincidentally generate the same key-pair (broken random generator / no entropy available / etc.), then both users would share the same account and one could block the other by deactivating the account. The other user would indeed have to generate a new key and account in this very unlikely case.

On the other hand it would also imply that there is a serious problem with the key generator.

4 Likes

Maybe I'm not reading that correctly...
But I hear "Can I use the same PUBLIC key to request another account?"
I'm not 100% certain how accounts are assigned, so that may be better answered by someone else.
But now, if the account can be derived from the public key... What is the point of the account? They essentially become one and the same.
So, I can only assume that the account is the key, NOT the public key used to obtain an account; and that they are NOT one and the same.
Therefor, the public key is not relevant to this "account" restriction.

1 Like

Sorry. I ment, if another used pick this exact same public key, will he be rejected with an unauthorized error message ?

I know it is unlikely, that two users pick the exact same public key, but it’s not impossible.

1 out of 2^2048 (or 3.23e+616)
Yeah very unlikely.

[I don't see why anyone would even consider such an event in their programming]

1 Like

Maybe because they are using a bad random number generator (happens in the best families). Though in that case a hard failure would be preferrable :slight_smile:

1 Like

I've tried to estimate this probability before, and there are at least two factors you didn't take into account:

  • Only probable-primes can be chosen by key generation routines for p and q, ideally with the goal that n=p×q must be a semiprime (the product of exactly two primes).
  • There is other logic to try to require n to be larger than some minimum value, so that we don't end up with a much shorter modulus at random. I think the most common interpretation is "a modulus which takes 2048 bits to write out in binary", which means a number between 2^2048 and 2^2049. I'm not sure whether that's the exact interpretation used by all key-generation routines, but running openssl genrsa 2048 | openssl rsa -modulus -noout | cut -d= -f2 | tr -d '\n' | wc -c many times shows that OpenSSL appears to use this interpretation. :slight_smile: (the hexadecimal representation of the modulus is always exactly 512 hex digits long, never, say, 511 or 510)

So the collision probability should be based on the number of semiprimes between 2^2048 and 2^2049 whose factors are roughly equal in size (potentially excluding some of them because the key generation deliberately or accidentally excludes some primes from being used in a key).

I think this is about the square of the number of primes from 2^1024 to sqrt(2^2049) (which is a bit smaller than 2^1025).

I just chose 1000000 integers at random in this range and 1425 of them were prime. If that sample were typical, that would mean there were roughly 106109615035909173991822291315914873021653897686062968341193540595665511543244825485791419726267136989394312557693091048073884629203739655747091199916336469562459901109366621456544966554847548011018687734419813914851962110837880014622865473073207030444050620634256500741057437943967654418934532734104462573 primes in this range, or around 10^305. The square of that number is around 10^610, which is then an extremely rough estimate for the number of 2048-bit RSA moduli.

The individual collisions according to this estimate are about three million times more likely than your estimate, but that's not very much at this level of improbability. :slight_smile:

Another thing to think about is the birthday paradox, relating to the probability that a collision will ever happen in a particular application of RSA.

2 Likes

You could simply use the Prime number theorem, which tells you that there are around sqrt(2^2049)/log(sqrt(2^2049)) - 2^1024/log(2^1024) = 2^1024.5 / 1024.5 / log(2) - 2^1024 / 1024 / log(2) = 2^1024 / log(2) * (sqrt(2) / 1024.5 - 1 / 1024) = 1.047346 * 10^305 primes between 2^1024 and sqrt(2^2049). That's only a bit smaller than your value :slight_smile:

There are also some bounds in the literature which will give a proper upper and lower bound, but for estimating the probability this value (same as your value) is more than fine!

Anyway, the chance that you can guess the private key used for AES-256 in one try is totally feasible compared to the chance that you generate the same random 2048 bit RSA key as someone else (assuming your random number generation is working fine).

2 Likes

The RFC states it must be rejected:

Relevant passage is in "11.1 Key Selection"

Last sentence, first paragraph page 87

Note that given the requirements of Section 7.3.1, servers will not create accounts with reused keys anyway.

Last sentence, second paragraph page 87

Because ACME accounts are uniquely identified by their account key pair (see Section 7.3.1), the server MUST not allow account key pair reuse across multiple accounts.

2 Likes

Seeing any such message would truly freak me out!
“Account creation failure: That exact account key pair has already been used - please try again.”

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.