From the Mozilla Open Badges Infrastructure community call Wednesday morning, it sounds like the signed assertions spec is ready. I’m exploring how signed badges work from a technical standpoint. Signed badges allow issuers to avoid storing an assertion file for each issued badge. Instead, issuers simply host a key that they use to “sign” badges, embedding a hash of some known content with the stored key. I am a newbie to encryption, so I wonder… How are badges signed and verified so that it is clear that only the issuer could have signed them?
- I suspect this involves a private key used to hash some known content, and this hash is attached to the badge itself along with the issuer’s contact info, but the private key is not known to the verifying party. If a public key is used to sign the badge, it could be faked by someone else who knows the public key.
- Then, what is the method used to sign the badge so that it is clear that only the issuer could have signed it, yet not allow anyone else to know the private key used to hash the value?
- What does the verifying party ask of the issuer’s server? What kind of work must be done by issuer’s server when a verification request comes in?
- Assertions Spec Wiki page.
- The “verify” field of the badge assertion contains a Verification Object. In the case of a signed badge, this contains a link to the web-accessible public key of the issuer. (specified in the
verify.urlproperty of the badge assertion.)
- “For compatibility purposes, using an RSA-SHA256 [as the payload/key hashing algorithm] is highly recommended.” RSA-SHA256 is a public key encryption protocol.
- Steps to verify a signed badge includes the instructions to fetch and store the issuer’s public key and then “With the public key, perform a JWS verification on the JWS object”. This seems to imply that the verifying party simply runs the public key through the hash algorithm.
- JSON Web Signatures (JWS) spec
- Three values are represented in a JWS: the JWS Header, the JWS Payload, and the JWS Signature.
- Usually presented as concatenization of these three strings, base64url encoded, joined by periods [#].
- “To validate the HMAC value, we repeat the previous process of using the correct key and the ASCII representation of the JWS Signing Input as input to the HMAC SHA-256 function and then taking the output and determining if it matches the JWS Signature. If it matches exactly, the HMAC has been validated.”[#]
- JSON Web Key spec
- API Authentication: HMAC with Public/Private Keys
- Not related to open badges: this post describes an authentication method that does not reveal the key used for signing to the world. This would be useful if using a different algorithm than RSA-SHA256 that didn’t use public/private key crypto.
- Acronym: Hash-based Message Authentication Code (HMAC)
- A method of determining the authenticity of a signed message by sending a request to the server (where public/private key pair is stored) that contains the public key, the unhashed payload and the asserted corresponding hashed-by-the-matching-private-key payload. The server then fetches the matching private key, re-hashes the payload with it, and returns true/false.
- Public key cryptography (Wikipedia) and their application on Digital Signatures
How are open badges signed so that they may be verified, yet may not be counterfeited?
- Using the RSA-SHA256 algorithm, the RSA private-key encryption is performed on a hash of the payload, and the RSA public-key decryption is performed on the same SHA256 payload hash. Thus, the issuer needs only to publish a public key in order to generate signed badges.
HMAC based algorithms are commonly used for passwords because MAC stands for Message Authentication Code — meaning both parties need to have the same code, or password, to then prove the source of the message without leaking the key to eavesdroppers. It’s a “shared secret”.
Public-private key signing, as opposed to general hashing and encryption, unlike HMAC, is about saying “I did this” without sharing the secret.
An algorithm, possibly the correct one, is: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-13#section-3.3
Here are some examples of the signing, though light on verification detail: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06#appendix-A.2
This clarifies that the RSA verify function is not the same as the signing function, but instead takes the corresponding public key as input.