Changes between Version 13 and Version 14 of security/electronic_signatures
- Timestamp:
- Mar 1, 2013, 2:47:03 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
security/electronic_signatures
v13 v14 7 7 8 8 == Implementation in VISTA == 9 Various parts of VISTA accomplish this using the encryption and decryption functionality. The encryption algorithm used is a stream cipher (I am not exactly sure which one). For TIU documents, the cipher algorithm uses the document's checksum of document contents as one of the vectors in the algorithm to encrypt the signer's name and title. If the document is modified outside of TIU, the user will see gibberish for these two fields.9 Various parts of VISTA accomplish this using the encryption and decryption functionality. The encryption algorithm used is a stream cipher. For TIU documents, the cipher algorithm uses the document's checksum of document contents as one of the vectors in the algorithm to encrypt the signer's name and title. If the document is modified outside of TIU, the user will see gibberish for these two fields. 10 10 11 11 For example, this is a typical signature: … … 26 26 27 27 == Use in VISTA outside of the VA == 28 The FOIA process removes sensitive security related algorithms from VISTA. As a result, those using VISTA outside of the Veteran's Administration have had to supplement this. I have surveyed all the external VISTAs a nd here is what I found on how they were replaced:28 The FOIA process removes sensitive security related algorithms from VISTA. As a result, those using VISTA outside of the Veteran's Administration have had to supplement this. I have surveyed all the external VISTAs available and here is what I found on how they were replaced: 29 29 ||Item||WorldVistA||!OpenVista||vxVista|| 30 30 ||!Access/Verify Hash||Reversible Hash||None||MD5 Hash … … 114 114 }}} 115 115 116 In addition, with Lloyd Milligan's permission, I used the extensible framework he has written to use tocall different algorithms based on configuration. The Public Entry Point, XUSHSHP, references these as follows:116 In addition, with Lloyd Milligan's permission, I used the extensible framework he has written to call different algorithms based on configuration. The Public Entry Point, XUSHSHP, references these as follows: 117 117 {{{ 118 118 XUSHSHP ;SF/STAFF - HASHING ROUTINE FOR SIG BLOCK IN FILE 200 ;2013-02-26 2:32 PM … … 145 145 146 146 The extensible framework uses the file UJO SUPPORTED API (400000001.1) to decide what code to execute. Each entry in this file defines an API that can be called externally from the 147 M umpsDatabase. Entries in UJO IMPLEMENTATION-SPECIFIC API (400000001.3) file are DINUMMED to this file and override the default implementation of the API specified in this147 MUMPS Database. Entries in UJO IMPLEMENTATION-SPECIFIC API (400000001.3) file are DINUMMED to this file and override the default implementation of the API specified in this 148 148 file if a DINUMMED entry is present in the other file. 149 149 … … 226 226 227 227 == How to implement == 228 To implement the changes in hashing and encryption, you need to perform conversions while users are offline from the system. The number of conversions you have to perform depends on the number of packages that use these features. In the world outside of the VA, these most likely will be the TIU and !Radiology/Nuclear Medicine packages, results in two conversions in addition to that of hashing the electronic signature.228 To implement the changes in hashing and encryption, you need to perform conversions while users are offline from the system. The number of conversions you have to perform depends on the number of packages that use these features. In the world outside of the VA, these most likely will be the TIU and !Radiology/Nuclear Medicine packages, which results in two conversions in addition to that of hashing the electronic signature. 229 229 230 230 As hashing is a lossy operation, it can only be done once from the plain text. To hash electronic signatures, you need to perform a loop on the new person file like this: … … 306 306 307 307 === Impact of the new encryption algorithm === 308 This area is far more problematic for two reasons: the output of the hash is random data (which Fileman cannot store, as it cannot store bytes which M umpsconsiders to be control characters), and with block ciphers input is padded to achieve block size. Both of these issues mean that to achieve proper encryption, you will need to base64 encode output from a block cipher so the result can be stored in Fileman. In the end, it means that the encrypted data is much longer than the original data (but not quite double the size). This means that we need to expand the Fileman fields where the encrypted data is stored. The KIDS file accompanying this article expands the 4 TIU fields that store encrypted data to 120 characters each from 60 characters. It's anticipated that other fields (especially field 10 in File 74) will need to be expanded depending on the number of packages you are using. The alternative is to change the encryption algorithm to something much weaker (even rot5) to be able to retain the current sizes.308 This area is far more problematic for two reasons: the output of the hash is random data (which Fileman cannot store, as it cannot store bytes which MUMPS considers to be control characters), and with block ciphers input is padded to achieve block size. Both of these issues mean that to achieve proper encryption, you will need to base64 encode output from a block cipher so the result can be stored in Fileman. In the end, it means that the encrypted data is much longer than the original data (but not quite double the size). This means that we need to expand the Fileman fields where the encrypted data is stored. The KIDS file accompanying this article expands the 4 TIU fields that store encrypted data to 120 characters each from 60 characters. It's anticipated that other fields (especially field 10 in File 74) will need to be expanded depending on the number of packages you are using. The alternative is to change the encryption algorithm to something much weaker (even rot5) to be able to retain the current sizes. 309 309 310 310 The following is an analysis of all the impacted area in VISTA: … … 384 384 385 385 == Future Direction == 386 In-MUMPS encryption can be decrypted by anybody who knows M umpswell enough, since the application needs to decrypt data for ALL appropriately authorized users. This is the reason that public/private key encryption will not work smoothly here without compromising security: if you are a different user, how would you decrypt a document encrypted using another user's or a machine's private key?386 In-MUMPS encryption can be decrypted by anybody who knows MUMPS well enough, since the application needs to decrypt data for ALL appropriately authorized users. This is the reason that public/private key encryption will not work smoothly here without compromising security: if you are a different user, how would you decrypt a document encrypted using another user's or a machine's private key? 387 387 388 388 However, it is best to emphasize that the encryption system used in VISTA is not there to encrypt data; rather it's there to assure its integrity.
