VistA-M and Delphi GUIs Problem

A recent message on the Hardhats mailing list exposed an interesting problem with an instance of VistA built from the code in OSEHRA’s VistA-M repository and a subset of VistA’s Delphi GUIs.  This problem lies in the cipher that VistA uses to encrypt and decrypt the Access and Verify codes during remote sign-on. 

The key to this cipher is found in two places: first in the XUSRB1.m routine and also in the Broker Development Kit for Delphi file named Hash.pas.  If the two keys are not identical on either side of a connection, the Access/Verify codes will not be decrypted to their original value and will likely be rejected by the EHR as incorrect.   This error manifests in the user receiving a “Not a valid ACCESS CODE/VERIFY CODE pair” pop-up message when attempting to sign on through a Delphi GUI but the user is able to log into the Roll-and-Scroll interface with the same set of codes. 

Due to an update to the VistA-M repository, specifically the addition of the code in the November 2014 FOIA release, the key for the cipher found in the XUSRB1 routine in the VistA-M repository has been changed. This change has caused a large amount of the available binaries of these GUIs to not be able to connect to an instance built from this version of the VistA-M code.

While OSEHRA does not have access to or a method to build from the source code of all of the VistA GUIs, we have prepared a version of the CPRS v30.15 executable that is compatible with an OSEHRA-built EHR instance.  It can be found on the code.osehra.org server at the following address:

http://code.osehra.org/files/CPRS/CPRSChart.exe

The executable has a SHA1 hash of 5dac623bcb253f3e065aa9a0050bb2f151dd448d for verification after downloading the file.

OSEHRA is currently determining the best course of action to take regarding the long term answer to the cipher problem.  Stay tuned for more information!

like0

Comments

Perhaps use the MS Windows registry?

DAVID Whitten's picture

Has the use of a Registry key been considered?

 If the code (which has to run on Windows anyway) retrieved the cipher
from a registry key (or if in MUMPS, it used a File (the COPYRIGHT
HOLDER FILE #601.3 comes to mind) or PARAMETER entry) then the code
would not have to be constantly recompiled to have a new cipher key
compiled in.

like0

VistA-M and Delphi GUIs Problem

Chris Uyehara's picture

Do exactly what Mr Edwards did in 2012 - revert the XUSRB1 routine in the
repo.

On Thu, Mar 26, 2015 at 5:28 AM, whitten <whitten@netcom.com> wrote:

> Has the use of a Registry key been considered?
>
> If the code (which has to run on Windows anyway) retrieved the cipher
> from a registry key (or if in MUMPS, it used a File (the COPYRIGHT
> HOLDER FILE #601.3 comes to mind) or PARAMETER entry) then the code
> would not have to be constantly recompiled to have a new cipher key
> compiled in.
> --
> Full post: http://www.osehra.org/blog/vista-m-and-delphi-guis-problem
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/4888
>

like0

What Patch?

Eduardo Brito's picture

Do we know the patch that changed this HASH

like0

Unfortunately, it isn't a

Joseph Snyder's picture

Unfortunately, it isn't a patching problem.  The change is made during the redaction process that each FOIA release goes through prior to its release.  

like0

Use obfuscation for security theater; encryption for security

K.S. Bhaskar's picture

The technique discussed here is obfuscation of data in motion, not encryption. Obfuscation is security theater, and deters amateurs. Detering real attacks requires real security, which in this case means encryption.

My short term recommendations are

  • Implement obfuscation of data in motion by whatever method is expedient and requires minimal effort on the part of the VistA community.
  • Deal with security not by modifying VistA, but with a documented strong recommendation to implement encryption for data in motion using TLS (with an external package such as Stunnel), Port forwarding over an ssh connection, or VPN.

In the long term, VistA should use TLS directly, with certificates on both sides.  Note that VistA should not itself include cryptopgraphic code, but it can use TLS built into the underlying infrastructure.

like0

Is the above implementation better than this:

Danny Nguyen's picture

https://scotthelme.co.uk/squeezing-a-little-more-out-of-your-qualys-score/

Or does this only handle the channel but not the encryption of the data going through the channel? Also why should vista not have cryptographic code to secure data on the file level when files are being sent? What about data at rest?

like0