A framework for the JOSE standards JWS, JWE, and JWK written in Swift.

Hello Airside/Mohemian team,

I needed EC algorithms for signing/verifying JWTs, and for decoding/encoding JWKs, so I thought it prudent to fork JOSESwift. The functionality for JWS and JWK should be complete and working, but I've yet to mirror your comprehensive test suite for RSA to the EC domain. I will be doing so over the coming weeks 🙂

Anecdotally, JWK decoding/encoding and JWS verification are working for ES256 public keys for the project I'm working on.

This is a WIP, tell me if there's any issues with it. It would be good to see this eventually hit upstream so we can retarget to master.

Cheers,

Jarrod

Still working on it guys. Will also add tests but would be nice to get a quick review.

Wondering about the Encrypter.swift and Decrypter.swift changes. If something else is needed there, can you point me to some documentation?

Thanks

Hey guys. Ill be working in closing the RSAES-OAEP PR today. Wanted to open this request for comments in order for us to start discussing what would be the best approach to add support to A256-GCM, Ill be offline tomorrow, flying to Brazil and would be nice if I have some ideas to read during the weekend. ;)

Hello,

I've tried to sign JWS ES256 with a key generated from the Secure Enclave (kSecAttrTokenID = kSecAttrTokenIDSecureEnclave).

The signing fails inside EC.swift -> let status = SecKeyRawVerify(publicKey, .sigRaw, digest, digest.count, signatureBytes, curveType.signatureOctetLength).

I've also tried changing the code a bit, with: SecKeyCreateSignature(privateKey, .ecdsaSignatureMessageX962SHA256, test as CFData, &error) instead. The signing passes, but the JWS is invalid.

Do you have any suggestions regarding this issue?

Thanks, Martin

Description

• Added a more secure asymmetric key algorithm to support industry standard encryption: RSA-OAEP-256. RSA1_5 is deprecated and not recommended for use in securing sensitive data.
• Documented all changes and provided external links to RFC pages.
• Added a few helper methods to provide easier testing coverage.
• refactored encryption and decryption unit tests to allow for future growth by allowing a developer to iterate over all the AsymmetricKeyAlgorithm enum cases.

Incremented version number to 1.4.1

Example Use (Swift String extension methods)

JWE Encryption using an RSA public key

func encrypt(with publicKey: SecKey) -> String? {
    let header = JWEHeader(algorithm: AsymmetricKeyAlgorithm.RSAOAEP256, encryptionAlgorithm: SymmetricKeyAlgorithm.A256CBCHS512)

    guard
        let messageData = self.data(using: String.Encoding.utf8),
        let encrypter = Encrypter(keyEncryptionAlgorithm: AsymmetricKeyAlgorithm.RSAOAEP256, encryptionKey: publicKey, contentEncyptionAlgorithm: SymmetricKeyAlgorithm.A256CBCHS512),
        let jwe = try? JWE(header: header, payload: Payload(messageData), encrypter: encrypter) else {
                return nil
    }
    return jwe.compactSerializedString
}

JWE Decryption using an RSA private key

func decrypt(privateKey: SecKey? = nil) -> String? {
    guard
        let privateKey = privateKey ?? CryptoEngineState.keyChainPrivateKey,
        let decrypter = Decrypter(keyDecryptionAlgorithm: AsymmetricKeyAlgorithm.RSAOAEP256, decryptionKey: privateKey, contentDecryptionAlgorithm: SymmetricKeyAlgorithm.A256CBCHS512),
        let jwe = try? JWE(compactSerialization: self) ,
        let payload = try? jwe.decrypt(using: decrypter),
        let decrypted = String(data: payload.data(), encoding: .utf8) else {
            return nil
    }

    return decrypted
}

Unit Tests

Provided full unit test coverage for the new asymmetric RSA-OAEP-256 algorithm.

Fixes #109

Description

Add an additional argument for the kid parameter (defaults to nil) when initializing JWEHeader. So it can be called with a kid parameter or easily without. So this is not a breaking change.

// With kid
JWEHeader(algorithm: .RSA1_5, encryptionAlgorithm: .A256CBCHS512, keyIdentifier: "kid")

// Without kid
JWEHeader(algorithm: .RSA1_5, encryptionAlgorithm: .A256CBCHS512)

The additional parameter gets set to the internal parameter dictionary, so when reading out the value of kid the value gets returned.

let header = JWEHeader(algorithm: .RSA1_5, encryptionAlgorithm: .A256CBCHS512, keyIdentifier: "kid")
print(header.kid) // "kid"

Tests

I added a test for this.

Update Documentation

I am not quite sure how the contribution-flow should look like for editing the Wiki as I can't put the changes of the Wiki here into this PR. So, I updated the README and added the keyIdentifier parameter when initializing the JWEHeader. But, I think, an extra information in the wiki would be nice. I opened a new issue #111 with updated content for the wiki, you can then use the content from there to update the wiki.

The JWS and JWE specifications dictate that the 'jwk' header parameter should be represented as a JWK (https://tools.ietf.org/html/rfc7515#section-4.1.3 & https://tools.ietf.org/html/rfc7516#section-4.1.5). The JWK representation is a JSON dictionary, and not a string, as currently implemented by JOSESwift.

This pull request is a suggested solution. It is also a work in progress, as the implementation of the 'jwk' header getters is sub-optimal and a better approach may be more desirable.

This pull request also does not provide test coverage, and short-circuits some tests in benefit of successful compilation.

An algorithm for symmetric JWE key (A128KW, A192KW and A256KW) encryption and decryption was added. Marius (@mtamu) is the owner of this implementation.

Hello,

Is it possible to include claim names https://tools.ietf.org/html/rfc7519#section-4.1 like:

iss (issuer): Issuer of the JWT
sub (subject): Subject of the JWT (the user)
aud (audience): Recipient for which the JWT is intended
exp (expiration time): Time after which the JWT expires
nbf (not before time): Time before which the JWT must not be accepted for processing
iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT
jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)

on the payload? Is there a proposed way to do this? I see that that JWSHeader contains some exposed properties.

Thanks.

This PR changes the EC crypto implemenation to use SecKeyCreateSignature and SecKeyVerfiySignature for signature creation and verification and adds the required conversions to and from BER encoded ASN.1 format for the signatures. It also introduces negative tests for EC signature verification, to detect trivial false acceptances for the signature validation. This is important because the tests for the signing also rely on the validation implementation.

See #155 for the discussion which lead to this PR.

Please be thorough with the iOS side of the review, since I do not have that much experience as developer for iOS.

Resolves #117.

Implemented this today throughout the day. Submitting the pull request now, so I can continue implementing feedback tomorrow at work.

• Allows encoding and decoding of [String] JWK parameters in addition to String parameters.

Tell me what you think!

⚠️ This contains two API changes in JWS.swift (major release needed):

subscript(parameter: String) -> String?
// becomes
subscript(parameter: String) -> Any?

let parameters: [String: String]
// becomes
let parameters: [String: JWKParameterType]

Summary

Enable the use of private header parameters by exposing the parameters dictionary

Private header parameters are currently not supported by JOSESwift. However, RFC-7516 describes their use. One way to support this is to publicly expose the parameters used by the JWEHeader and JWSHeader classes. This enables users of the library to extend the header classes with any custom parameters they require.

Changes

Makes the parameters dictionaries used by JWEHeader and JWSClasses public.

Caveats

There might be reasons we do not want to allow direct access and modification of the parameters variable on headers. In that case, a different implementation is needed to comply with RFC-7516. Any and all feedback is welcome.

Tests

The tests pass. No changes needed.

Compilation fixes for tvOS and XCode 14.0.1

Includes the change from https://github.com/airsidemobile/JOSESwift/pull/273, and updates for Xcode 14.0.1

After considering the comments in #251, I've added support for content encryption using AES GCM according to JWE standard. As I've mentioned there, I increased the minimum iOS target to 13.0 because of CryptoKit.

Currently, the header parameters are strictly defined and I couldn't find a way to extend them with custom ones.

In JOSEHeader and its implementations, parameters can only be accessed internally so that you can't define custom parameters outside of this library.

Would it make sense to make parameters public? Or any other idea how custom header parameter names can be accomplished?