summaryrefslogtreecommitdiffstats
path: root/base/kra
Commit message (Collapse)AuthorAgeFilesLines
* Consolidated log() for audit events.Endi S. Dewata2017-06-278-72/+24
| | | | | | | | | Duplicate log() methods for audit events have been merged into the Logger class. https://pagure.io/dogtagpki/issue/2689 Change-Id: I7a5147ff3221a52a82e69f56faf2156c04256db2
* Refactored signed audit logger.Endi S. Dewata2017-06-248-122/+43
| | | | | | | | | | | | | | | Signed audit logger creation has been simplified into: Logger signedAuditLogger = SignedAuditLogger.getLogger(); The null checks on signed audit logger have been removed since it cannot be null. Audit messages can be logged as follows: signedAuditLogger.log(message); https://pagure.io/dogtagpki/issue/2689 Change-Id: I3bf781b0194a6cbb166f71751c098d1c2a3a657a
* Fix token enrollment and recovery ivsAde Lee2017-06-161-0/+6
| | | | | | | | | | In encryption mode, the archival of the geenrated key uses the wrapIV, while the recovery uses the encryptIV. To make sure these are consistent, they need to be set to be the same. Bugzilla BZ #1458043 Change-Id: I1ecece74bd6e486c0f37b5e1df4929744fac262b
* KRA PKCS #12 export: add config to use 3DES PBE encryptionFraser Tweedale2017-06-091-11/+32
| | | | | | | | | | | Restore the 3DES PKCS #12 key recovery code path, alongside the new AES variant, which is broken on Thales nethsm. Add the 'kra.legacyPKCS12' config for selecting which version to use, with the default value of 'true' (i.e., use 3DES). Part of: https://pagure.io/dogtagpki/issue/2728 Change-Id: Ic02fe8ba3a4c2c049913ff48d3f6dfdc830b4360
* Server side changes to correctly parse the new PKIArchiveOptionsAde Lee2017-06-071-12/+9
| | | | | | | The server is modified to read the new OIDs in the PKIArchiveOptions and handle them correctly. Change-Id: I328df4d6588b3c2c26a387ab2e9ed742d36824d4
* Fix NPE in audit log invocationAde Lee2017-06-023-4/+8
| | | | | | | | | | Some audit log objects take a RequestId or KeyId, on which we call toString(). In some cases, we were creating a KeyId or RequestId with null values, resulting in an NPE. We fix these in this patch. Bugzilla BZ# 1458043 Change-Id: I38d5a20e9920966c8414d56afd7690dc3c11a1db
* Set encryption flag for generated keysAde Lee2017-05-263-3/+3
| | | | | | | | | | | The key record for keys generated in the keygen servlets was not updated to reflect whether or not the server was set up to do encryption/key wrapping. This patch corrects this oversight. Bugzilla BZ# 1455617 Change-Id: I31daece8b93a0ad58cb595e6a23fe8705f338024
* Replaced SHA1-based random number generators.Endi S. Dewata2017-05-252-2/+8
| | | | | | | | | The SHA1-based random number generators in some classes have been replaced with the random number generator provided by JssSubsystem. https://pagure.io/dogtagpki/issue/2695 Change-Id: Id0285dbc8c940fa7afb8feccab3086030d949514
* Encapsulate server side keygen audit eventsAde Lee2017-05-252-21/+17
| | | | | | | | | This encapsulates key gen events for the token servlets. Consolidated the success and failure cases. Note that this event can likely later be replaced with security_data_keygen events. Leaving separate for now. Change-Id: I6caaeb2231fd2f7410eade03cb5fa93d66444bbf
* Encapsulate key status change audit logsAde Lee2017-05-251-9/+7
| | | | Change-Id: I57b30cdff571056d0a95436858308872a8dc007b
* Replaced random number generator in SecurityDataProcessor.Endi S. Dewata2017-05-251-6/+19
| | | | | | | | | The SecurityDataProcessor has been modified to use the random number generator provided by JssSubsystem. https://pagure.io/dogtagpki/issue/2695 Change-Id: Ibca684a2165266456c4b28cba5eae4136940d189
* Encapsulate symmetric and asymmetric keygen audit eventsAde Lee2017-05-243-29/+26
| | | | Change-Id: Ifc8d05bd1d2d34bb0ef25877f838731bed58d00e
* Simplify recovery audit loggingAde Lee2017-05-243-38/+72
| | | | | | | | | | | | | | | | | Currently, when we use the retrieveKey() REST interface, there are two logs generated for the processing of a recovery request. To rectify this, logging has been removed from the lower level in the SecurityDataProcessor and is delegated to the higher level. This necessitated adding audit logging to the SecurityDataRecoveryService, which processes recovery events asynchronously. In addition, the logging in retrieveKey() has been pushed down to the retrieveKeyImpl, because there is at least one success exit point in retrieveKeyImpl where a recovery request is created, but no key is exported. Hence in this case, a KeyRetrieve success event is not warranted. Change-Id: I0725e6fe82046ae666bf6c81d6a6ba58261dfc87
* Make sure archivalID is passed through archivalAde Lee2017-05-245-17/+54
| | | | | | | | | | | | | | | | There was some confusion in the previous commit for archival logging. The archivalID is the id provided by the CA for the archival and is its requestID. This allows the cert request operation to be tracked through the archival. Made sure therefore, that we have two fields - one for the archivalID and one for the requestId (which is the KRA archival request ID) In addition, some of the archival events occur in the CA component just before the request id sent to the KRA. These events will not be displayed unless the audit event is added to the CA CS.cfg. Change-Id: I3904d42ae677d5916385e0120f0e25311b4d9d08
* Fix failing audit logAde Lee2017-05-241-2/+2
| | | | | | | | | | | | As currently written, the audit log for completing the cert processing on the KRA will always fail because the cert is not yet issued. The cert is only issued after the key is archived. Basically, though, this particular log is only suppposed to be written to the CA audit log. Rather than adding a subsystem check, the simplest solution is to not expose this event on the KRA. Change-Id: I9e658dca15fd87e87c0124c4c9972dbca2910643
* Encapsulate recovery request approval audit logsAde Lee2017-05-231-5/+4
| | | | | | | | The audit logs where an agent grants an asynchronous recovery request and the case where recovery request is appproved from the REST API are consolidated and encapsulated in a class. Change-Id: I237c1dcfc413012d421f3ccc64e21c7caf5a7701
* Fix auditing in retrieveKeyAde Lee2017-05-232-18/+72
| | | | | | | | | | | | The auditing in retrieveKey is all messed up. * Added new audit event to track accesses to KeyInfo queries. They may produce a lot of events, especially if events are generated for every listing of data. By default, this event may be turned off. * Added audit events for generation and processing of key recovery requests. Change-Id: Icb695e712bdfadf0a80903aa52bd00b9d4883182
* Encapsulate key retrieval audit eventsAde Lee2017-05-233-17/+19
| | | | | | | | | | | Key retrieval is when the key/secret is extracted and returned to the client (once the recovery request is approved). We combine SECURITY_DATA_RETRIEVE_KEY and a couple of older EXPORT events. Note: an analysis of the key retrieval rest flow (and the auditing there will be done in a subsequent patch). Change-Id: Ibd897772fef154869a721fda55ff7498210ca03c
* Eliminate async recovery audit eventsAde Lee2017-05-232-45/+34
| | | | | | | | | There are now many ways to recover keys. From an auditing point of view, its not helpful to distinguish between sync or async requests. So we just use SECURITY_DATA ... Change-Id: Id64abd56248c07f3f7f7b038ba5ac458af854089
* Encapsulate recovery processed audit eventsAde Lee2017-05-234-193/+132
| | | | | | | | This creates audit events for KEY_RECOVERY_PROCESSED and SECURITY_DATA_RECOVERY_PROCESSED audit logs. We simplify by reducing the logs to the SECURITY_DATA ones. Change-Id: I75968799dec48d1f056ba15f8125d3bd031f31bb
* Encapsulate key recovery audit eventsAde Lee2017-05-237-39/+61
| | | | | | | | Encapsulate SECURITY_DATA_KEY_RECOVERY_REQUEST and KEY_RECOVERY_REQUEST audit events as audit event objects. We have collapse to a single audit event type. Change-Id: I68c27573725cf27c34d008c58847d6a22e0d0bac
* Encapsulate archival processed audit logsAde Lee2017-05-235-35/+36
| | | | | | | | Encapsulate audit logs for SECURITY_DATA_ARCHIVAL_REQUEST_PROCESSED and PRIVATE_KEY_ARCHIVAL_REQUEST_PROCESSED. We have merged the two audit events. Change-Id: I2abc7edff076495bb62733b92304fecd4f15b2b7
* Encapsulate the archival audit logAde Lee2017-05-235-107/+40
| | | | | | | | | | | | | This patch encapsulates the SECURITY_DATA_ARCHIVAL_REQUEST and PRIVATE_DATA_ARCHIVAL_REQUEST audit logs as audit events. The PRIVATE_DATA_ARCHIVAL_REQUEST events are mapped to the SECURITY_DATA ones to simplify the whole structure. They used to provide an archivalID parameter which was pretty much meaningless as it was at best just the same as the request id which is alreadty logged. So this is now dropped. Change-Id: I705d25ce716c73f2c954c5715b0aafdad80b99d2
* Fix symmetic key retrieval in HSMAde Lee2017-05-063-3/+15
| | | | | | | | | | | | | | | | | When using an HSM, AES KeyWrapping is not available and so some different code paths were exercised. Fixing bugs in those paths uncovered a case where we were calling unwrapSymmetric() with bits and not bytes for the key length. This does not matter for 3DES, where JSS expects a length of 0, but very much matters for AES. Fixing this - and the KeyClient to actually use the returned wrapping algorithm to unwrap, allows us now to return generated symmetric keys correctly. Bugzilla BZ#1448521 Pagure: 2690 Change-Id: I2c5c87e28f6f36798b16de238bbaa21da90e7890
* Use AES-CBC in storage unit for archival in key wrappingAde Lee2017-05-068-21/+26
| | | | | | | | | | | | | When AES-KW or AES-KWP is not available, we need to be sure to use a key wrap algorithm that is available for keywrap. This would be AES-CBC. Removes some TODOs. Refactor so that getWrappingParams is only defined on the StorageUnit, which is where it makes sense in any case. Part of Bugzilla BZ# 1386303 Change-Id: I28711f7fe0a00e9d12d26c6e170fb125418d6d51
* Make sure generated asym keys are extractableAde Lee2017-05-063-196/+196
| | | | | | | | | | | | | | | In HSMs, we were not able to retrieve asym keys that were generated from the AsymKeyGenService, because the right flags were not set (ie. set like in the server side keygen case). To do this, I extracted the key generation function from NetKeygenService to KeyRecoveryAuthority, so that it could be used by both services. Bugzilla BZ# 1386303 Change-Id: I13b5f4b602217a685acada94091e91df75e25eff
* KRA: use AES in PKCS #12 recovery for wrapped keysFraser Tweedale2017-04-291-11/+13
| | | | | | | | | | | | | | | | | The KRA has two private key recovery code paths: one dealing with keys wrapped to the storage key, and one dealing with symmetrically encrypted keys. Each has a separate function for constructing a PKCS #12 file for the recovered key. This commit updates the PKCS #12 generation for wrapped keys to use AES encryption. The JSS PBE facility is not expressive enough to handle PBES2 encryption, which is necessary for many algorithms including AES, so we now use CryptoStore.getEncryptedPrivateKeyInfo. Part of: https://pagure.io/dogtagpki/issue/2610 Change-Id: Iba67f15642338316e4a6d09f78504327e8853b85 (cherry picked from commit 8e663b6270d9a9409a04bfcb445318a6d5622b52)
* KRA: do not accumulate recovered keys in tokenFraser Tweedale2017-04-261-1/+1
| | | | | | | | | | When using token-based unwrapping of archived keys, the key is being stored in the token. We do not want to accumulate the keys here; make them temporary. Part of: https://pagure.io/dogtagpki/issue/2610 Change-Id: Ic12a4db7238512b4fec5d6fdb023b20195c2d438
* Refactored additional line concatenation.Endi S. Dewata2017-04-202-29/+9
| | | | | | | The code that concatenates lines has been simplified using String.replace(). Change-Id: Id376f089cb9b8a78cfd9b3fb922e9cd9055c0e74
* Allow key recovery to use encrypted field in key recordAde Lee2017-04-133-12/+33
| | | | | | | | | | | | | | The previous commit added a field in the KeyRecord to specify whether or not a key was encrypted or key wrapped when archived. This patch modifies the recovery servlets to use this field to determine how to decrypt/unwrap the key for transport. Absence of this field in the key record implies that is an old record - and we use the value of the CS.cfg parameter as the default. Change-Id: Ia8ae679e8b3fe8462d42848d614bff863ef68e50
* Add field to indicate if key was encrypted or wrappedAde Lee2017-04-135-6/+15
| | | | | | | | | | | | | | | | Whether a secret was encrypted or wrapped in the storage unit depends on a parameter in CS.cfg. If that parameter is changed, the Storage unit may use the wrong mechanism to try to decrypt the stored key. Thats ok for encrypt/wrap using DES or AES-CBC, but not for AES KeyWrap. In this patch, we add a field in the Key record to specify whether the secret was encrypted with stored (or keywrapped if false). A subsequent patch will change the logic when decrypting to use this field. Change-Id: If535156179bd1259cfaaf5e56fd4d36ffdb0eb0e
* Fix symkey retrieval in python clientAde Lee2017-04-131-14/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keys (like symmetric keys and asymmetric keys) are returned from the KRA either encrypted or key wrapped. Because the AES keywrapping algorithm cannot be decrypted using AES CBC, we need special logic to unwrap the keys. The flow here is as follows: 1. When a key retrieval request is sent to the server, the client sends the encryption and key wrapping algorithms it requires the key to be wrapped along with the wrapping key. 2. If no encryption algorithm or key wrap algorithm is recieved, the server assumes its talking to an old client and uses DES3. 3. The key is retrieved and (on server's choice) is wrapped or encrypted. The return package will have either encryption or key wrap algorithm set (depending on how the key was encrypted/wrapped.) 4. client uses that to determine how to unwrap key. This patch: 1. Makes sure the key wrap algorithm requested by client is passed through and used to wrap the retrieved key. 2. Adds logic in the python client to unwrap/decrypt. 3. As python-cryptography does not yet support AES KeyWrap with padding, the python client is configured to request AES-CBC by default. Change-Id: I4ba219bade821249b81e4e9a088959c27827ece1
* Added methods to log AuditEvent object.Endi S. Dewata2017-04-137-0/+69
| | | | | | | New audit(AuditEvent) methods have been added alongside the existing audit(String) methods. Change-Id: Ia02a7daa8b9e8693208fe34309d8d727cc32ce54
* Reorganized additional audit event constants for KRA.Endi S. Dewata2017-04-124-88/+53
| | | | Change-Id: Ib4586443f7e6f759d227975f9736cdd30b8f32e8
* Reorganized audit event constants for KRA.Endi S. Dewata2017-04-125-43/+16
| | | | Change-Id: Ic4a79b0c73812c7b89daca3c804e6a88c738536a
* Add KRAInfo resourceAde Lee2017-04-111-0/+4
| | | | | | | | | | This resource (which will be accessed at /kra/rest/info) will initially return the mechanism for archival or retrieval. This is needed by clients to know how to package secrets when archiving. Change-Id: I6990ebb9c9dafc4158e51ba61a30e773d1d953ec
* Added CLIs to access audit log files.Endi S. Dewata2017-04-041-0/+3
| | | | | | | New pki audit commands have been added to list and retrieve audit log files. Change-Id: I785fa6f55d9b143f513d9210ebf82d04e06eaed5
* Added audit service and CLI to all subsystems.Endi S. Dewata2017-04-044-0/+23
| | | | | | | Previously the audit service and CLI were only available on TPS. Now they have been added to all subsystems. Change-Id: I3b472254641eb887289c5122df390c46ccd97d47
* Change default key size for KRA storage unit to 128Ade Lee2017-04-031-1/+1
| | | | | | | Most of the research out there seems to indicate that AES-128 is more than sufficient for security. Use this as default. Change-Id: Ie333282eacc5ce628c90296561e4cd6a76dcbd8e
* Removed redundant Context attributes.Endi S. Dewata2017-03-312-34/+0
| | | | | | | All subclasses of PKIService have been modified to remove the Context attribute since they have been declared in the base class. Change-Id: Icdbe97efa2b910a579264099f817930c2cc2ed1a
* Misc pylint, flake8 and tox fixesChristian Heimes2017-03-312-2/+3
|
* Fix retrieval for symmetric keysAde Lee2017-03-282-22/+42
| | | | | | | | | | | | | Up to now, we have only ever used the same algorithm (DES3_CBC) for key wrapping and encryption. With the change to use AES Keywrap and AES CBC, we need to know which mechanism was used to encrypt/wrap the secrets when returned to the client. This means passing back more information to the client with the key data, and also modifying the client to use this information to decode the data correctly. Change-Id: I7232085c1eedf38c63abad81db08acc912fa1da1
* Added audit logs for SSL/TLS events.Endi S. Dewata2017-03-281-2/+2
| | | | | | | | | | | | | | | The CMSStartServlet has been modified to register an SSL socket listener called PKIServerSocketListener to TomcatJSS. The PKIServerSocketListener will receive the alerts generated by SSL server sockets and generate ACCESS_SESSION_* audit logs. The CS.cfg for all subsystems have been modified to include ACCESS_SESSION_* audit events. https://pagure.io/dogtagpki/issue/2602 Change-Id: If7fb6c1b096ec8c68d1fd08f9132baf099816f11
* Modify storage unit to generate a new IVAde Lee2017-03-247-30/+59
| | | | | | | | | | | | | | | | | Currently, the storage unit reuses the same IV each time a record is stored. This works (probably) for DES3, but not for AES. The getWrappingParams() method is modified to check the config as follows (in order): -- if the iv is defined, use that iv -- if the length is defined, generate a byte array of that length -- return null To ensure that the same IV used to encrypt the secret is stored in the DB, the wrapping param is defined once in the archival process, and passed in to the wrapping functions in storageUnit. Change-Id: Ia6696adf56fc7a4e90f83948c7549b64a38ab854
* Refactor code that creates PKIArchiveOptions objectsAde Lee2017-03-238-790/+32
| | | | | | | | | | | | | | * Refactor code in CryptoUtil to parametrize the algorithms used. * Moved WrappingParams to utils jar to allow correct compilation. * Removed code that created a PKIArchiveOptions structure from CRMFPopClient and replaced with calls to CryptoUtil methods. Note that the algorithms have been left as DES3. They will be changed to AES in the next patch. * Converted code in AuthorityKeyExportCLI to use the new methods in CryptoUtil. * Removed DRMTest this code is no longer maintained or used. Change-Id: I8f625f0310877dca68f6a01285b6ff4e27e7f34a
* Fix Java client to use AESAde Lee2017-03-211-16/+18
| | | | | | | | | | | | | | | | | | | | | | * Changed the client to use AES-128-CBC-PAD rather than DES-3. Because AES-256-CBC-PAD has no OID defined, we use the following hack: * Pass in the AES-256-CBC OID as the encrypt algorithm OID * Use PKCS#1.5 Padding. * Changed the client to use AES for the wrapping key on retrieval. * Changed the server to implicitly assume PKCS#1.5 (and a key size of 128) when recieving the OID for AES. * Changed the client to send, and the server to pass through the encryption algorithm expected when retrieving the key. * Fixed the generate_iv() function to generate an appropriately sized IV on retrieval. This code has been tested to successfully create and retrieve secrets using AES. Ideally, we'd be using GCM rather than CBC, which then requires no padding - and no hack needed. Hopefully, we can get that working in a subsequent commit. Change-Id: Ic9e8d50169be0fe357a48a5a1b1c452c7a3dfad0
* Add config options to allow storage wrappings to be setAde Lee2017-03-163-10/+69
| | | | | | | | | | Wrapping params can now be specified in CS.cfg as per design. The default will be AES. If the parameters are not set, then the old mechanism (DES) will be used instead. A migration script will be created in a separate commit. Change-Id: I01a74b99c4ed127d66e5b766357af59a1147839d
* Merge branch 'master' of github.com:dogtagpki/pkiAde Lee2017-03-1511-696/+588
|\
| * Continue to move more crypto into CryptoUtilAde Lee2017-03-145-94/+56
| | | | | | | | Change-Id: I6024ca5a32769b460d578dfad46598432381784c
| * Refactor crypto codeAde Lee2017-03-148-227/+134
| | | | | | | | | | | | Move some of the crypto functions in EncryptionUnit to CryptoUtil. Change-Id: Iee391392fb88a87f6af3b450b69508fd52729a62
generated by cgit (git 2.34.1) at 2024-10-01 05:10:03 +0000