Silverlight, Flash, PDF and other Online Form Techniques

[Target Audience: Developers and System Administrators]

There seems to be growing interest for an online form service allowing customers to collect input from users and send it back as structured information to organizations, while preserving confidentiality including input, transmission, archive, access, and auditing functions.

The ability to enable customers to style online forms, for different server scenarios including absence of server-SSL input protection, should also be part of the available customer-design process. Further, the online form service should allow customers to use web forms, email forms, SMS forms, storage file forms, and any other communication process.

ZSentry is currently beta-testing such a Secure Online Form service that meets these considerations.

This work has led us to think more deeply about the pros and cons of Silverlight, Flash, PDF and other methods used to provide online form functions, as well as security and usability, which are the motivations for this posting and feedback.

In many cases of interest, the online form service must assure full HIPAA compliance. Safe Harbor compliance (even without HIPAA) is also coming to the foreground given the high profile and costs of recent breaches such as with Epsilon and Sony.

From the security viewpoint, and contrary to ZSentry for Google Apps (where both the need for HIPAA and Safe Harbor compliance can be satisfied by ZSentry), online forms as enabled by Google Docs cannot at this time be used by ZSentry as a basis for such secure service. The recent security breaches caused by phishing attacks against Google Apps and Gmail further highlight the concerns of storing plaintext information in online services such as Google Docs.

Our usability starting point is that online form functions are "critical" and, thus, in principle should be usable without asking the user to download or do anything else.

Usability is also necessary to ensure security, as we mention elsewhere (Usability is a system's #1 Security Property). In short, a secure online form service that is secure but not usable will not be used and, therefore, will actually fail to be secure. If security is too difficult or annoying, users may give up on it altogether.

Therefore, while it is OK for an information or help document to be available in PDF (with all the PDF requirements/problems to be met and solved at the user side), users can either view the PDF using any quick view software/service (including Google) or just move on to something else. Not so with an online form that needs to be entered.

We also see that many users are just that -- users -- and have no admin privilege in their devices. Increasingly, devices are locked (also by manufacturers -- see iPad vs Flash) for installation.

These concerns go against Silverlight. It could be better to use Flash (more widely available) but still many users would be left out as new Flash versions come out quite frequently and many users cannot update or do not like to bothered by yet another update. Silverlight also suffers from frequent updates.

How about JavaScript? It is commonly available. However, even JavaScript should only be used to provide added usability, while the online form itself should be functional without JavaScript. This is important not just because some devices have problems with JavaScript; some networks and services also block JavaScript.

In comparison, even though Silverlight or Flash based online forms may look more usable for corporate intranets and other special subsets of users, for public Internet users they are actually not as usable as HTML/CSS with optional JavaScript.

ADA and accessibility requirements also point to HTML/CSS with optional JavaScript.

In conclusion:

1. Knowing the target-user comes first, as it defines how the message needs to be delivered. Silverlight, Flash, PDF forms, and other non-HTML solutions can be used well in an intranet (internal services in a hospital, for example) where the organization can control the server, the network, the filters, all the clients, and what is installed and updated at any moment in those clients. Lacking that inclusive control, it is bound to fail in the public Internet for the same reasons.
2. From the user's viewpoint, HTML/CSS with optional JavaScript should be the best practice for online forms using the public Internet, as providing the needed functions while not standing in the way of using the online form -- which is the user's goal.
3. The ZSentry API for secure online forms is designed so that it can be used with any desired method, including HTML/CSS with optional JavaScript, Silverlight, Flash, PDF forms, and other interfaces. It is up to the developer to make the best use of it.

Comments are welcome. ZSentry for secure online forms is currently in beta test. Please submit a Support Ticket if you are interested in participating now or when the service is launched.

Cheers,
Ed Gerck

Sender-Defined Security

When you send an email to a recipient, who bears the highest risk?

Usually, you. Because the information is transferred from sender to recipient, the sender likely has the highest risk. The information may be valuable to both, but the sender is the party that can be found liable for (even if inadvertently) disclosing it to others. Email is risk-asymmetric.

For example, patients may initiate communications with a health care provider using unencrypted email, according to HIPAA. This is done at the patient's risk. However, providers may have concerns when replying to the patient using unencrypted email. Providers are subject to potential liability under the HIPAA Privacy Rule [see 45 C.F.R. § 164.530(c)], including their determination whether a patient is aware of the possible risks of using unencrypted email.

Since the sender is the party at risk, the sender needs to be able to define the security conditions, for example, for confidentiality, delivery, and tracking of the message.

Let's see how certified postal mail works. The sender chooses the service and the type of envelope to protect the message. The sender also chooses the instructions
that must be followed before the envelope can be opened by the recipient. The recipient has no charge to pay for, or burden, in order to receive the envelope, and does not have to do anything before the envelope is sent. The recipient is able to verify the identity of the sender and, if so desired, refuse the envelope. The recipient can open the envelope if and only if the recipient is willing to follow the sender's instructions (e.g., providing name, address, date, signature).

The same should be available for sender-defined security modes of operation for email.

Using IBE encryption (Identity-Based Encryption, Voltage, MessageGuard) does not work because IBE requires sender key-escrow, so that the sender is always at risk that her messages can be read by someone else.

Clearly, a conventional public-key model (PKI, X.509, PGP) cannot provide this functionality either. The security model for protecting email with public-key cryptography is backwards, technically and business wise. The sender, who is the party at risk, has to trust a lock provided by the recipient (his public-key) to protect her secrets (the message).

If certified postal mail would provide message security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince the recipient to pay and send in advance an envelope for the sender to use. The sender, however, would never know whether the envelope indeed prevented others from prying into its contents. Moreover, the recipient is not the business driver who needs to provide, pay for and protect the lock. The sender is the party who has the motivation to spend money to provide and protect the lock.

These are well-known and recognized standards for encryption of email. However, their security and usability problems noted above cannot be solved by improvements in usability, better pricing or user education regarding how IBE, PKI, X.509, or PGP work. It simply does not work as it should work. That's also why conventional secure email has been difficult to use. It has the wrong logic for the problem.

ZSentry is a security technology that was developed after these standards and improves upon them in both usability and security. ZSentry provides per-message encryption, authentication, message control, and auditing, protecting information in motion and at rest. ZSentry reduces the trust and control requirements in several critical areas, making it easier to attain and demonstrate a higher level of security while increasing usability.

Most importantly, ZSentry enables a secure email system that works closer to how postal mail, including courier and certified postal mail, works.

Because ZSentry mail can be delivered securely to both registered and also to unregistered users, the sender is able to define the delivery conditions that must be satisfied by the recipient before the message can be decrypted (delivered) in each case.

For example, based on what is at stake and what threats may apply, versus the usability requirements, the sender can select from the following delivery conditions:

Require Registration: (For higher security: use this option) The recipient must register before reading the message. After the recipient registers, delivery is further controlled by the Delivery option specified by you for registered users (see next items).

Require Login: (For higher security: use this option) The recipient must be registered and login before reading the message. To reduce risk, this process includes mailbox authentication, login monitoring, message expiration, and other control features.

Read Until Expiration: (For higher usability: use this option) Available for both registered and unregistered users. The recipient is allowed to decrypt the Zmail, including attachments (if any), as many times as desired until the message expires. The security of the Read Until Expiration mode is based on mailbox authentication, login monitoring, and expiration control. The sender can choose when to expire, where the sooner the better for security.

Reply to Sender: (available in all options, including without registration or login) This is a very useful choice to receive a secure reply, as the recipient has no burden to reply securely (can reply securely just with one-click).

The security of these Delivery choices is further enhanced by other choices, including for Control and Tracking, for example allowing the sender to choose a message self-destruct time and real-time audit reporting with a Return Receipt.
The Return Receipt is sent back to you with information on When, Where, How, and by Whom your message was read.

You can also compare the Return Receipt with the corresponding Send Receipt (available from the server, upon sending), closing the loop with potentially more comprehensive delivery and notary evidence than using courier or certified postal mail, with less cost and immediate delivery.

In summary, ZSentry puts the sender in the driver's seat of secure email, with more and more effective options than any other system including IBE, PKI, X.509, PGP, courier and certified postal mail.

How about password security?

Password security may look like yet another oxymoron, as two intrinsically contradictory terms. If it is a password, how can it be secure?

Indeed, there are many and valid security arguments not to use passwords. You can find a summary in the paper Take Five In Internet Security where, in a five-minute appraisal, we present and discuss a typical dialogue with someone claiming that they have a secure server while using username/password authentication.

However, not all passwords are created equal. ZSentry, for example, uses two-factor, strong authentication without passwords -- even though, for familiarity, the second-factor is called ZSentry Password.

This is important for usability, as passwords are easy to use.

The security difference is that ZSentry does not store your Usercode or Password, not even encrypted. This technology, called ZSentry Sans-Target, solves the vulnerability problems of common passwords, including dictionary attacks and password files, as described in the study Take Five In Internet Security.

The ZSentry technology eliminates common online targets such as username/password lists, names, email addresses, plain text user data, meta-data, and even the encryption/decryption keys themselves, while adding two-factor mutual authentication, adaptive security, and password-hardening.

The critical point is that ZSentry Sans-Target provides the best defense possible against data theft -- the best defense against data theft is to not have the data in the first place.

Another important point is that ZSentry is not as dependent on password quality for security, as conventional systems are. With ZSentry technology, passwords are paired with an unpredictable ZSentry Usercode, and both are not at risk anywhere.

Nonetheless, it is recommended that ZSentry passwords should include at least one control or punctuation character. All of the characters !@#$%^&*()_-+=[]|\;:"?/,.< >`~' and space can be used in ZSentry passwords (space cannot be used at the beginning or end of a password).

For advanced password use, for maximum protection, you can use ANSI codes from #32 to #255 (keyboard ALT-number, no space at the start or end of a password). This simple strategy enables more than 132 bits of entropy with just 13 ZSentry Password characters (and the Usercode).

The conventional difficulty for using ANSI codes in passwords is solved by the ZSentry function Password Peek (during signup and login). You can easily see and verify what you typed before you submit, even for ANSI CODES such as ALT-0159 for Ÿ (Latin Capital Letter Y With Diaeresis).

With ZSentry, you can now use passwords as securely as you want.

Large EMR privacy breach notification, two years later -- an exception or a symptom?

NOTE: A colleague and I are working on a paper discussing a number of  privacy and security red flags that can help call attention to these and other issues, especially in the context of secure email. A draft is gladly available to those who are interested, by private email request, for comments before  publication. 
 
Electronic medical records (EMRs) are at the heart of health care reform, and there is both a personal as well as a legal expectation of privacy for EMRs.

Promptly notifying users of privacy breaches can help bring accountability to the system, and help users.

In February 2010, RelayHealth (also known as NDCHealth Corporation) acting as a claims processing company, notified prescription holders that EMRs of two years ago, dating between February 2008 and December  2008, with full name, date of birth,  prescription number, insurance cardholder ID, and drug name, that were  dispensed at Rite Aid as well as other retail chain pharmacies and  independent pharmacies in the State of California, were sent to an  unauthorized pharmacy.

After I mentioned this case online, RelayHealth has contacted us in March 2010 and stated  that the data was sent in error only in November 2009, so the delay in informing consumers was not two years but three months.

However, we note that this information was not provided to RelayHealth's consumers when the privacy breach was disclosed in February 2010.  RelayHealth may want to look into that communication and verify why they did not disclose a delay of three months.

Further, what matters to our analysis here is the consumer privacy risk, which includes the two-year delay.  If, for example, three-year old files are wrongly disclosed today and the EMR processor informs the patient tomorrow,  this is not a lesser problem for the patient (as the next mentioned Fortis case exemplifies).

The 2010 breach notification did not disclose why the information was sent (Who requested it? Under what authorization? Who approved it?), who incorrectly received  the EMR, and who was responsible for the breach, neither what compensation or recourse users may have.

In a recent court case, Fortis (a US health insurance company) was found to have a practice of targeting policyholders with HIV. A computer program and algorithm targeted every policyholder recently diagnosed with HIV for an automatic fraud investigation, as the company searched for any pretext to revoke their policy.

Companies such as Fortis can find out about anyone's diagnosed HIV, or other illness, through pharmacies and claim processors, for example.

This situation underscores the underlying conflicts of interest between at least three distinct roles that RelayHealth plays. They are:

1. claims processor;
2. provider of patient EMR to their pharmacies and doctors;
3. provider/seller of EMR to providers other than the patient's.

This last activity has the greatest potential conflict, as patients are included in a no-opt-out policy at www.RelayHealth.com that says (words in square brackets are comments, not from RelayHealth):

"Your Provider, a Provider-Designated User [pretty much anyone] or  authorized member of a Provider Group  [anyone] can use contact and/or health information about you stored by RelayHealth for many purposes including [ie, this  says that it does not exclude anyone or anything]:
..."

and

"RelayHealth may use the contact, billing and/or health information [EMR] provided by you in our service to provide your physician or other healthcare provider [ie, anyone they want]  with updated and/or supplemental information for their files or systems." 
 
A pattern that seems to emerge here is that because EMRs also have a market value (for example, to insurance companies, pharmacies, etc.), health care service companies can build automated information exchanges where they can make collected EMR available to other entities, and build a business on this activity.

That the same health care service companies (with different hats) also serve on behalf of the patients to protect the EMR from disclosure, is where the fox is taking care of the hens, and where the conflicts in 1-2-3 may play a role.

What this means is that the expansion of health care into larger use of EMRs ought to call for a much broader review of procedures and conflicts of interest than what is currently available. And, obviously, it should also include stricter rules for information security and handling of EMRs than what's currently used.

Your comments are welcome.

Best regards,
Ed Gerck

Discussion summary on improving SSH

SSH (OpenSSH) is a workhorse for secure web administration and, as such, important for managing Internet servers including email. SSH is, usually, the only way to access remotely located servers. Of course, this makes SSH a valuable attack target.

There are established practices for securing SSH. However, they currently rely substantially on additional systems, that also present their problems and add to the maintenance burden.

After some discussion in the cryptography@metzdowd.com list and in private, I present below a summary of the dialogue and clarifications with a view to improve SSH. I've divided it in sections A-F, to make it easier to discuss.

A. THE SIX SSH ISSUES
The free test tool Nessus allows a remote SSH server to be quite easily discovered and explored by automated scans & attacks. The information obtained in SSH server scans can be typically divided (from the view point of a sys admin) in six issues (to be discussed later, this is just a list):

1. no way to block scanning and attacks
2. does not learn from attacks
3. advertises itself and the server OS
4. allows empty authentication requests (eg, requests by invalid users)
5. sends host key fingerprint to invalid users (eg, with no username)
6. sends a reply to invalid users (eg, with no username)

These issues, alone or in combination, can lead to multiple vulnerabilities, some with higher security significance than others (according to operational factors as well).

B. CRYPTO
Let's first state that not all the six issues are created by crypto use in SSH. And this leads us to the main question here:

Could new crypto in SSH help mitigate or solve any of these six issues?

Currently, how are these issues addressed? By non-portable and potentially buggy methods (see below), with more software that has to be patched, updated, configured and tested, all at different times, with added security gaps that can be compromised.

New crypto methods in SSH could do a better job by reducing the problems in the first line of defense at SSH itself and by avoiding security gaps. Non-crypto things such as PAM, tcpwrapper, port-knocking, grey-listing and others can always be added later anyway, if desired.

C. PASSWORDS
Some issues could be minimized by turning off password authentication, to use only private/public keys (PKs). SSH allows users to generate PKs without cost (no need for a CA). Users can keep their private keys in their drives and also in a USB dongle, for example. One can also add second-channel authentication (e.g., RSA SecurID) to SSH with a PAM or a patch.

However, turning off password authentication is not desired in many cases, even when PKs and second-channel authentication are used.

Password authentication may be more secure against attacks on the client, to gather information before compromising the server. According to Peter Gutmann, a study of SSH attacks a few years ago showed that nearly two thirds of all SSH private keys were stored on disk with no password protection at all, so that simply being able to read a hard drive will get you access to any number of systems without having to trojan the SSH client or plant a keyboard logger as you'd need for an SSH password. So turning off password authentication could make things less secure, not more.

Another reason for using passwords in SSH, and perhaps more compelling, is that you don't want to risk getting locked out just because your disk died, you forgot your laptop, SecurID or USB dongle, and the private key cannot be found (for security reasons!) in the back-up. Passwords can also easily be given over the phone from sys admin to sys admin, and are easily protected by threshold cryptography. And using a private/public key pair in SSH would anyway require a password for protecting the private key.

Using good, high-entropy passwords turns out to be preferred by many sys admins because it is simpler, more portable, and works fine for security (provided the password is chosen with enough entropy). Sys admins already need to use many passwords for many servers and protocols, and have safe methods for off-line storage, redundant record keeping, and authorized record access (including a handwritten notebook, encrypted USB dongles, and a printed list), that are of course not kept near the computer.

D. PAM
Some of the issues can be solved with SSH PAM, such as pam-abl. However, PAM libraries are usually buggy (buggier than SSH), and might be unstable unless suitable PAM items were added by which the daemon can communicate the client IP address and port number, and maybe other things too.

E. SOLUTIONS
I believe that each one of the issues 1-6 can be met by a cryptographic protocol deployed in SSH. Some solutions are well-known. BTW, there were some similar issues in the SSL protocol.

F. ISSUE BY ISSUE REVIEW

#1. no way to block scanning and attacks

Firewall port-knocking can help here. It is hard to guess and defeat; nothing shows up in scanning. However, it is not portable and is hard to debug and use.

While there are also IDS that can turn off the SSH port if a scanning is detected, this can lead to DoS.

Pam-abl can also help, but PAM is usually buggier and adds security gaps.

Possible solution: SSH could easily incorporate some of the pam-abl code, enough to block an IP for some time T after N failed attempts, self-clearing after T.

#2. does not learn from attacks

Possible solution: SSH can incorporate some of the pam-abl code for this purpose.

#3. advertises itself and the server OS

"Need to know" is a valuable security policy.

Advertising the OS may compromise a higher security function (the OS) in the case of a zero-day or unpatched exploit. SSH MUST NOT advertise the OS. It may compromise policies and apps in a lower (more critical) layer than SSH, not just the OS.

Also, advertising SSH's innards in "already dead" authentication has no useful purpose that could not be more securely met.

Possible solution: let the client tell its version to the server, for the server to decide if it is acceptable -- it is a server function anyway (eg, not to accept SSH v1).

Additionally, it would also be useful for the client to send to the server a list of acceptable configurations, for the server to select, so that the server would no longer be groping in the dark as to what algorithm and parameters to use.

#4. allows empty authentication requests (eg, requests by invalid users)
#5. sends host key fingerprint to invalid users (eg, with no username)
#6. sends a reply to invalid users (eg, with no username)

- Some claim that the SSH protocol requires key exchange to occur before the user identity is sent, as it protects the user identity from disclosure to an impersonator.

However, if the user does not have a valid username, why and what should the server have to prove to that user? Invalid data deserves either "no response" (safer) or an error response. The SSH server should not do work or provide information to an user that is known already to be invalid. The SSH protocol needs improvement here.

- Some also claim that if the SSH protocol would permit such differing responses for valid/invalid users, then attackers can use SSH as an oracle to determine username validity.

However, SSH can prevent username enumeration by trial and error. With a simple keyed-hash, if this protection is desired, one would just enter the same key for the server and clients, so they can be all using the same transform. This is a simple mechanism that hackers cannot break by guessing. Note that SSH already uses a hash mechanism to hide domain names in the hosts file.

- Some claim that the issues #4 and #5 are actually "features" that are used by some of the anonymous services, such as anonymous CVS.

However, these "features" could be closed by default, and opened in the sshd config file if desired. This may also need some cryptographic protocol changes.

Because the reported issues could be improved by adding crypto, I am asking for more input first, before taking these issues to the OpenSSH development list. This should help the development effort. The OpenSSH development mailing list is at:
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Thanks for all the input! Comments are welcome.

Cheers,
Ed Gerck