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:
<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
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 Spring beans file....
<bean id="encryptionService" class="org.kuali.rice.core.service.impl.NoEncryptionEncryptionServiceImpl" />
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
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.
Kuali documentation is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.
Kuali software is licensed for use pursuant to the Affero General Public License, version 3.
Copyright © 2014 Kuali, Inc. All rights reserved.
Portions of Kuali are copyrighted by other parties as described in the Acknowledgments screen.
Kuali ® is a registered trademark of the Trustees of Indiana University.