OpenID Connect Core 1.0 section 7 "Self-Issued OpenID Provider" looks quite
insecure.
The subject identifier "sub" (that RPs will use as the identifier for an
account) is calculated from a hash of the concatenation of n & e (for an RSA
key). However, the boundary between n & e is not preserved. Hence there are
lots of other public keys that will give the same "sub". Using any of these
other keys will allow an attacker to impersonate the user of this self-issued
OP. These other keys do not have the same security as the user's real key.
The example from the spec is below:
{
"iss": "https://self-issued.me";,
"sub": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
"aud": "https://client.example.org/cb";,
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"sub_jwk": {
"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
"e":"AQAB"
}
}
The same "sub" results even if the key (sub_jwk) is changed as follows to have
a public exponent of 0. That makes it easy to sign! "AQ" is moved from the
start of the "e" to the end of "n".
"sub_jwk": {
"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgwAQ",
"e":"AB"
}
The same "sub" also results from the following key that has a modulus half the
size (hence far far less security). Half the modulus is moved to the exponent.
"sub_jwk": {
"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2",
"e": "QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgwAQAB"
}
There are similar problems with elliptic curve keys, or even with replacing an
elliptic curve key with a weak RSA key that gives the same "sub".
[If we had a canonical form of JSON we could hash that, otherwise... include
the key type and some delimiters]
--
James Manger
_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
