Encrypting a Field
Secure fields may be stored in the database in encrypted form. An OJB converter will be created to decrypt/encrypt going from and to the database. This converter must be specified in the OJB field-descriptor tag for the field, like so:
| Code Block |
|---|
| xml |
|---|
| xml |
|---|
| title | org.kuali.kfs.fp.ojb-fp.xml |
|---|
|
<descriptor-repository version="1.0">
...
<class-descriptor class="org.kuali.kfs.fp.businessobject.DisbursementVoucherWireTransfer" table="FP_DV_WIRE_TRNFR_T">
...
<field-descriptor name="disbVchrPayeeAccountNumber" column="DV_PAYEE_ACCT_NBR" jdbc-type="VARCHAR" conversion="org.kuali.rice.kns.util.OjbKualiEncryptDecryptFieldConversion"/>
...
</class-descriptor>
</descriptor-repository>
|
The Encryption Service
| Anchor |
|---|
| encryption_service |
|---|
| encryption_service |
|---|
|
All encryption is done through a core "encryption" service. The various points in the frameworks will call this central service for the actual encrypting/decrypting. Institutions wishing for different encryption algorithms can simply override the encryptionService Spring bean. For example, say you want to turn off encryption for development purposes, you can just add the following to your override the appropriate Spring beans filefiles....
| Code Block |
|---|
|
<bean id="encryptionService" class="org.kuali.rice.core.service.impl.NoEncryptionEncryptionServiceImpl" /> |
| Warning |
|---|
As stated, KFS comes with two implementations of EncryptionService: NoEncryptionEncryptionServiceImpl and DemonstrationGradeEncryptionServiceImpl. Neither are advisable for use in environments with actual sensitive data. However, the Java SE comes with a number of encryption algorithms which can be used in an institution specific implementation of EncryptionService. Interested parties should look at this document on Java Cryptography Architecture (JCA) Reference Guide to find choices that come prepackaged with Java. Very interested parties should look at Bruce Schneier's excellent books, including the classic Applied Cryptography. Most institutions likely also have a security officer or task force who would be very interested in the institution specific implementation of the EncryptionService interface. Naturally, changing the encryption algorithm will mean that the encryption key will need to be a valid key for the algorithm, and that the size of encrypted values will be different from algorithm to algorithm. If a stronger encryption algorithm is implemented, then the database field widths of encrypted values may have to be made much longer. Again, the point here is that implementing institutions should not, under any circumstance, use the KFS pre-packaged EncryptionService implementations to encrypt secure or sensitive data entered within KFS. |
The Encryption Key
| Anchor |
|---|
| encryption_key |
|---|
| encryption_key |
|---|
|
Of primary importance to practically all encryption algorithms is the encryption key. The key needs to be held in a location where KFS can access it but where non-administrative users have no access to it. The DemonstrationGradeEncryptionServiceImpl uses the encryption.key property in the kfs-security-default-config.properties file (database connection properties also exist in this file). The encryption.key configuration property should be overridden. Again, protecting the encryption key is crucial to the integrity of the encryption system.
...