[OPENAM-6272] Allow storing the shared secret in an encrypted format for the ForgeRock Authenticator (OATH) Module Created: 30/Jun/15  Updated: 26/Jun/17  Resolved: 21/Jul/15

Status: Resolved
Project: OpenAM
Component/s: authentication
Affects Version/s: 12.0.0
Fix Version/s: 13.0.0

Type: Improvement Priority: Major
Reporter: Tanveer Ahmed [X] (Inactive) Assignee: Neil Madden
Resolution: Fixed Votes: 0
Labels: AME, CustomerRFE, Newton, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Target Version/s:
Sprint: Sprint 90 - Team Newton
Support Ticket IDs:

 Description   

It should be possible to store the shared secret for HOTP and TOTP in an encrypted format instead of the current Base16 encoded format. This is probably a common requirement for banking related institutions or anything that requires more complex security.



 Comments   
Comment by Neil Madden [ 16/Jul/15 ]

Andy Hall Do we know where the key for encrypting the key should come from?

Comment by Neil Madden [ 16/Jul/15 ]

As the device profile is stored as JSON currently, suggest that we change it to be a JWT. That way we can apply our standard authenticated encryption algorithms, which support both symmetric AES and asymmetric RSA. However, we currently only implement AES-128 in commons JWT, so I'd need to update that too

Comment by Neil Madden [ 16/Jul/15 ]

I can update the commons json-crypto to support AES-256 fairly easily, I think.

Support for RSA-2048 may be simple or difficult, depending on what exactly they mean by that Andy Itter? The JWT library supports a mode whereby the contents of the JWT (i.e. the device settings, including the shared secret) are encrypted using AES (CBC mode, with HMAC for authentication) using a fresh random "Content Encryption Key" (CEK). It is then just the CEK that is encrypted using RSA, as RSA directly is only really safe for encrypting keys or other "random" material, so couldn't be used to encrypt the whole device settings (there would be enough predictable plain text there to recover the RSA key). Would this be appropriate for what they want, or do they want just the shared secret to be directly encrypted using RSA-2048 (in which case a JWT solution is not appropriate)?

Comment by Neil Madden [ 21/Jul/15 ]

Andy Hall There is an open question here about what you want to happen to existing device settings when encryption is enabled/disabled? As I've currently implemented the solution, it will fail to read the existing profiles and an admin will need to delete/recreate them. We could either bulk-convert them all when changing the setting (potentially expensive) or lazily change them as we encounter them, but both would require additional work.

Comment by Neil Madden [ 21/Jul/15 ]

This is implemented in trunk. Note that AES-256 support will not fully work until CREST-301 and CREST-302 are merged into forgerock-rest, but no additional OpenAM changes are needed to pick that up (just rebuild OpenAM against the updated snapshot and use a JRE with JCE Unlimited Strength installed). AES-128 support works immediately.

Generated at Sat Oct 24 01:11:25 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.