170.302 (o-v) Security requirements

From OpenEMR Project Wiki

General Encryption 170.302(u)

The NIST rules require documentation that the EHR is capable of providing encryption/decryption of data. These third party tools meet that need in my opinion. --Tony - www.mi-squared.com 01:22, 4 March 2011 (UTC)

ICSA (Amit) says: Yes – SSL, and Windows EFS and/or TrueCrypt can be configured to meet the requirements in the test procedures. Basically we would run through the test procedure and verify that the software was configured accordingly, and when the product was listed on the CHPL (Certified Health Product List), we would list whatever additional 3rd party software was used to meet the requirements during testing. --Tony - www.mi-squared.com 06:53, 5 March 2011 (UTC)

Tests with ICSA on Friday indicate the need to add one more function to the document management model. This will be a enhancement to the SHA1 hash key model used to meet "Integrity tests". --Tony - www.mi-squared.com 20:19, 13 March 2011 (UTC)

The requirement is:

We'll do this by adding a optional encryption/decryption prompt to the document upload/download module. We have chosen php_mcrypt as the library to use for this and TripleDES as the cypher. Future enhancements could add a pick list of availble FIPS 140-2 approved cyphers.

Example of screen to download AND encrypt a document

Download-with-encrypt-v2.png

Example of upload with decrypt option

Upload-with-decrypt.png


Basic Visolve Actions

   (1) Audit log - its a straightforward change.
   (2) User Passwords -
      (a)  For New installations - again its a straightforward change
      (b)  For Upgrades -
       Isolated one issue:
          -- Already existing users will have their passwords encrypted in MD5
           -- If we change the algorithm to SHA1, how the existing MD5 passwords are validated?
       
        Our proposed solution (only after upgrade):
        (a) When the user logins, the length of the password string is retrieved.
        (b) If the lenght is less than 40 bytes, the user is validated with MD5 and allowed to login 
              1. On successful login, the user is prompted to "reset his/her password"  
                 (This activity has to be forced through some mechanism)
              2. If fails, it lands again to login page.
         Note:
            SHA1 and MD5 have different hash lengths.
            The MD5 hash is 128 bits (or 32 bytes as a hex string); The SHA-1 hash is 160 bits
             (or 40 bytes as a hex string)

Integrity SHA1 170.302(s)

Email discussion moved to discussion tab --Tony - www.mi-squared.com 19:05, 3 March 2011 (UTC)

Implementation Generate/Display and confirm HASH Key

for Integrity NIST Tests

Document-screen.png

Validation that failed due to tampering

Validate-failed.png

New features:

  • On upload form, add a "Destination File" field so that the user can rename the file as it's being uploaded.
  • On upload, generate a SHA-1 hash code and store it in the database documents table along with the file's meta-data
  • When browsing the document, provide a method for renaming the document (See screenshot)
  • When browsing the document, provide a visual method of validating the document's integrity by displaying it's hash code (see screenshot). When the user clicks "validate," we will run the SHA algorithm over the file in its current state, and make sure that the hash codes match. Visual feedback will be provided to the users using a popup displaying the original hash, and the newly generated hash, and a message stating whether or not the values match.
Retrieved from "https://www.open-emr.org/wiki/index.php?title=170.302_(o-v)_Security_requirements&oldid=12400"