Email-Security

Electronic Medical Records -- the new email frontier?

2011-07-17T23:00:00.000-07:00

The statistics regarding the impact of EMR (Electronic Medical Records) on efficiency seem far less than encouraging. As commented privately to me, in more than one occasion, significant net drops in provider efficiency are the norm, despite the hype.

The push for EMR adoption on the part of the government and payers is about data, not provider productivity (at least not the kind of productivity that improves a provider's bottom line). A 6% penalty on Medicare billing or a $64,000 incentive is small compared to the real cost of EMR adoption for many providers. The gap between what providers are being sold on and reality could hardly be broader in the industry...

So, the reality is that today's EMR is a really hard thing to do well, as also evidenced by the reported high numbers of failed EMR conversions and large number of second EMRs (replacing a first EMR).

Electronic Medical Records -- the new email frontier?

In contrast, using encrypted email can be much easier for adoption and even provide an EMR basis IF it can complement rather than replace an email system. It should require no changes in the user GUI, no learning, no commitment in other areas, no change to any other aspect of the operation, and should have low cost compared to the base system (email).

This is exactly what ZSentry at http://zsentry.com has been providing, as a complement system to Google Apps, Outlook, iPad, and other existing email solutions, enabling HIPAA and HITECH Safe Harbor (the next need after HIPAA) practically "out-of-the-box".

And ZSentry can also be used as part of a local EMR, allowing secure communication in and out of it. One such hybrid ZSentry/EMR system has recently been certified by the DHHS in the US ARRA program.

So, Yes, albeit the statistics on current EMR efficiency are not encouraging, we can start with simpler systems that are, well, simpler to work with.

How about the future?

If we see the statistics of CNC (Computer Numerical Control) adoption in the early 50's in the US, in the 70's for word processors, and other IT application examples, including the Internet itself, we will see the same trend of less efficiency, frustration, followed by exponential, unbelievable at the time, improvements in efficiency, cost, quality, and every other parameter (except when people look at direct employment reduction as a downside, rather than as an opportunity for progress).

Now, ask yourself how much would it cost to run an IT company the way a physician runs his office today?

For example, how many people-hours/day are used faxing in a practice today? And faxes are not even HIPAA-compliant...How long can this waste go on?

It's just natural that the future comes with a shock-wave. But automation-driven efficiency improvements grow fast and are worth the trouble. The U.S. Census Bureau took eight years to complete the 1880 census, but just one year for the 1890 census. The difference then: automatic tabulation with Hollerith cards.

Now, fast-forward to the US health-care sector in 2011. What's happening with the SOHO and SMB health-care markets? They are shrinking fast since ca. 2000, and becoming far more competitive in price. For example, the share of solo practices among members of the American Academy of Family Physicians fell to 18 percent by 2008 from 44 percent in 1986. And US census figures show that in 2007, just 28 percent of doctors described themselves as self-employed, compared with 58 percent in 1970. Many of the provisions of the new health care law are likely to accelerate these trends in the health care sector.

Because efficiency will become even more critical for the survival of solo and small practices, they may be more likely to use simpler, secure email first and move to EMR as possible. I doubt they will continue to use fax, or even dare to ask their patients to run to the pharmacy with a written prescription, or refill by phone. Larger health-care providers may also see faster returns by using simpler systems first. Keep It Simple -- and I see no need for adding a second S at the end.

Ed Gerck

Email vs Postal Mail Security

2011-06-29T15:45:00.000-07:00

"If can send this document by postal mail, why can't I email it?"

Saying that email is like a postcard, that anyone can read and even write on, is usually not enough to highlight the differences. After all, there are so many emails out there, people think, that email is "protected by numbers." And anyone can also open my envelope and read my postal mail.

What's the difference?

To further clarify the difference, it is useful to consider the different roles of an email service provider versus a postal mail or courier service in terms of security of medical records. A health care organization (HCO) must comply with HIPAA (medical records privacy rules) to assure the privacy of a patient's Protected Health Information (PHI). To send PHI, the HCO has a legal obligation to sign a Business Associate Agreement (BAA) with any service provider that may become aware of the PHI, assuring that the PHI will be protected as determined by HIPAA.

The US Post Office and courier services do not need to have a BAA to transfer mail. It is legally understood in HIPAA terms that the usual "sealed envelope" is enough to protect the PHI and deny potential access to it by the service provider -- even though access is clearly possible by the service provider personnel, and would require just opening the envelope.

However, "opening the envelope" would have to be done by someone first going through the physical access controls of the mail provider, is a physical act that can be done only one envelope at a time, takes time and space, can be observed and reported by a co-worker or someone else (including video surveillance). Typically, several people need to be involved and would need to collude in an entire mesh of secret events. Further, "opening the envelope" is still likely to leave traces that the recipient can see.

This is not the case with electronic records, such as electronic PHI (ePHI). A factor that militates against ePHI is the fact that although paper and electronic records are both vulnerable to subversion, it is a lot easier and faster to read what is in an electronic record somewhere, or search for specific information, than it is to read or search what is on paper in a closed envelope.

HIPAA enforcement and patients are also well aware that electronically one can read, search, and even modify a million records with as little as a few keystrokes, for example from a cybercafe in Moldavia or somewhere in China.

These are critical vulnerabilities that need to be addressed when using ePHI - for example, that mass disclosure and potential subversion can be so readily accomplished from the safety of a remote laptop or phone, and that it would be unavoidable or even undetectable.

To answer these concerns, the email provider must demonstrate a number of barriers, including defense in depth. This should be based not only on cryptographic assurances, but how they are distributed, and how ePHI entering the email provider is bound to communication channels in a manner that the ePHI is rendered demonstrably inaccessible to an attacker, both through physical access controls and through cryptographic protocols.

Moreover, the email provider should include a step-by-step description of the process, available for auditing, so that when someone asks, "What if the intruder succeeds in breaking into the system to change X?" this can be clearly answered, for example, by (i) to change X would cause a subsequent binding failure, thus it would be detectable except with parallel access to Y and Z, which are independently inaccessible; or (ii) knowledge of an alternate (and attacker-desirable) value for X is computationally impossible to achieve during the PHI lifetime period, and the effort could not be leveraged to any other X.

In short, the email provider should use not just cryptography but also other techniques to make it is as impossible as desired to tamper with the PHI. This includes server actions to protect each client and to protect the servers from malicious use of the clients.

In addition to the foregoing barriers, "opening the envelope" by the email service provider staff or online attackers would require having the keys to do so. However, where and how to securely keep the keys from insiders, and who watches the watchers?

Looking at NASDAQ, Epsilon, Citibank, and other high-profile "secure service provider" breach cases in 2011, shows a bleak view as not even large organizations could prevent such attacks.

However, these requirements can be easily met by an email service provider using the ZSentry Sans-Target technology, because online servers and personnel simply do not have the keys to do it, there is no copy of the keys anywhere, and the keys are too large for a trial-and-error attack to succeed in practice.

Further, ZSentry treats the email body as a "data blob" and does not scan it. There is also no condition whereby the ZSentry service or personnel could be made aware of the ePHI, providing even stronger protection for an email service provider using ZSentry services for encryption.

Therefore, in addition to assuring that the ePHI is encrypted and de-identified, an email service provider can use the ZSentry technology to technically prevent anyone, including own personnel and online attackers, from breaking the encryption or the de-identification.

More info in answer to the question "Why is ZSentry secure?" in http://zsentry.com/security-email-faq.htm

Silverlight, Flash, PDF and other Online Form Techniques

2011-05-28T09:31:00.000-07:00

[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:

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.
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.
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

NMA ZSentry API -- Frequent Questions

2011-04-23T09:31:00.000-07:00

[Target Audience: Developers and System Administrators]

The NMA ZSentry API is a secure software service that works in your environment. You can use the API both in a server as well as in a client context. There is no plugin or installation. With the ZSentry API you can readily connect, send, and store information securely, for example as a secure email, enabling secure communications in desktop, cloud, and mobile platforms, anywhere.

What is the NMA ZSentry API?
An SMTPS (SMTP over SSL, also called implicit SSL) service. You use the ZSentry API to connect your system to the ZSentry engine using TCP port 465 for encryption and decryption directly or through a message service or application. The resulting secure emails are encrypted per message and can be sent using ZSentry's own SMTP server, without requiring SSL, or can use another resource as a mail relay with or without SSL.

Why port 465?
With port 465 there is no ZSentry data exchange without SSL, including the ZSentry Usercode and Password data. Contrary to the submission port 587 with STARTTLS where the connection changes from non-SSL into SSL, port 465 has SSL-at-connect required. We prefer port 465 because every connection is encrypted from the start, preventing problems such as the SSL bridge attack (a well-known problem also for web browsers).

What server-side applications and servers are compatible?
The ZSentry API complies with IETF standards. ZSentry tested the API using servers with the dovecot/postfix Debian implementation and other Linux flavors. Customers have tested the API with a variety of Linux and Windows technology, including System.Net.Mail, CDOSYS (Collaborative Data Objects, Cdosys.dll), VB6, PHP, Java, and Sybase PowerBuilder.

Do users need to use ZSentry App (the web interface)?
No, not necessarily. The ZSentry API sends secure email that can be read and decrypted using the ZSentry App as well as leading Mail clients without any plug-in. This means that with the ZSentry API there is no web browser security and usability limitation for users, and users do not need to use the ZSentry App for reading, sending and saving secure messages. However, the ZSentry App can be used in a webmail environment.

How about Google Apps and Gmail?
Web mail services including Google Apps and Gmail can be set up to send HIPAA-compliant secure email using the ZSentry API directly, as a cloud Mail client with Single-Sign-On. This can be done by users, without an add-on or installation. Reading and saving secure email can also be done through Google Apps and Gmail,
using ZSentry App in the webmail environment or a Mail client.

How are Mail clients used?
Mail clients can be set up to send, read, and save HIPAA-compliant secure email using the ZSentry API directly, with Single-Sign-On. The user only sees the Mail client GUI for sending, reading and saving messages. This can be setup by users, without a plug-in or installation. A web browser is still used on the client side, but it is used transparently as a middleware and not as a GUI.

What clients are compatible?
The ZSentry API complies with IETF standards. Compatible clients include any major web browser, Outlook, Outlook Express, Windows Mail, Apple Mail, Entourage, Thunderbird, iPhone, Android, and iPad, on Windows XP, Vista, Windows 7, Linux, Mac OS X and iOS.

What applications can be used at the client side?
Clients can use several applications including webmail, email, IM, SMS, and file storage services.

Can I debug the SSL/SMTP flow?
Yes. This is a typical SSL/SMTP trace enabled by the API and which you can also capture in normal use to log delivery evidence for your service:
--------------
SMTP -> FROM SERVER:220 mail.example.com ESMTP Postfix
SMTP -> FROM SERVER: 250-mail.example.com 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-
AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
SMTP -> FROM SERVER:250 2.1.0 Ok
SMTP -> FROM SERVER:250 2.1.5 Ok
SMTP -> FROM SERVER:354 End data with .
SMTP -> FROM SERVER:250 2.0.0 Ok: queued as E519A5801F4
-------------------------

More Information:
http://zsentry.com/zapi.htm

Sender-Defined Security

2011-03-22T16:54:00.000-07:00

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?

2011-02-26T15:33:00.000-08:00

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.

The Technical Problem of Information Security

2011-01-30T16:28:00.000-08:00

This article provides an in-depth look into Information Security and End-to-End Security. What is the problem, what can we do about it, and how effectively?

This discussion presents the technical requirements for an End-to-End IT security solution, summarized in four points:

integrate core security services;
eliminate known weak or costly links such as password lists, access control databases, shared secrets, and client-side PKI;
avoid the seemingly desirable scenario of a single point of control, which is recognized as a single point of failure;
bind a coherent system of trust to the solution and to its users.

The NMA ZSentry solution is mapped as an example of a system that complies to these requirements and provides a cost-effective implementation.

The technical problem of information security can be stated, quite simply, as "to avoid too much concentration of information and power, while allowing enough information and power so as to make a task possible to execute."

For example, an all-knowing, all-powerful entity would be the perfect attacker and could break any security measure.

That is why we oftentimes talk about "need to know" and "separation of powers." We name these principles, respectively, information granularity and power granularity.

Such principles mean that information should not be provided in its entirety to a single entity and one should also avoid the scenario where any entity is, at the same time, user, administrator and auditor. That is why business information and power should be carefully divided, for example, among local employees, the office management, the enterprise management and the customer.

Also, contrary to what is oftentimes advocated in regard to IT security solutions, there should be no single point of control in an IT security system, which point must be recognized as a single point of failure -- i.e., no matter how trustworthy that single point of control is, it may fail or be compromised and there is no recourse available because it is the single point of control.

One of the earliest references to this principle can be found some five hundred years ago in the Hindu governments of the Mogul period, who are known to have used at least three parallel reporting channels to survey their provinces with some degree of reliability, notwithstanding the additional efforts.

Tools such as authentication and authorization can help define information and power granularity. However, at its most basic level, a secure IT system needs to do much more than just control authentication and authorization.

No matter how much assurance is provided that each component of a secure system is correct, when operational factors such as collusion, internal attacks, hackers, bugs, viruses, worms or errors are taken into account, the system may fail to be effective -- i.e., may fail to be secure in the context of its operational use.

In addition, underlying assurance problems such as insecure operating systems and reoccurring buffer overflow vulnerabilities are not likely to improve over the coming years.

There is a real need, thus, to bring together policy, management and implementation considerations that could influence effectiveness assurances for each particular IT security solution.

Other security principles such as redundancy, diversity, and least privilege also need to be used in defining the specific requirements for a secure IT system. In addition to being specific, such requirements need to be clearly formulated, decidable and, as much as possible, complete.

Additionally, an end-to-end design is important to assure effectiveness, because attacks and errors are hard to detect and prevent at the interface points. End-to-End (E2E) security is defined as safeguarding information in a secure telecommunication system by cryptographic or protected distribution system means, from point of origin to point of destination

For lack of paper trails or other material proof, non-repudiation is also often essential for Internet and IT security systems. A common definition states that non-repudiation is about providing proof that a particular act was actually performed, for example as demonstrated by a trusted time-stamp. However, this definition is etymologically incorrect and, thus, should be repudiated. It also misses the point. We and other authors prefer to define non-repudiation as "preventing the false denial of an act". In other words, it is not enough to provide proof of an act, as a denial may be presented and create a tie. While a correct denial should win the tie, a false denial should not.

To be effective, non-repudiation needs to take into account technical and business considerations. For example, bank checks are non-repudiable in the sense that a check is paid if (1) you did not tell the bank beforehand that the check should not be paid and (2) the signature does not look like a signature you did not make. The reader should note the double-negative, which provides less room for customer repudiation -- the signature does not have to look like a signature that you made, it just has to not look like a forgery.

Commonly, IT secure systems also must satisfy security standards such as the Controlled Access Protection (C2) level of security as defined in DoD 5200.28-STD (the Department of Defense Trusted Computer System Evaluation Criteria), the ITSEC Level 3 as defined in the Common Criteria for Information Technology Security Evaluation, or the Code of Practice for Information Security Management BS 7799 (a British Standard that is the basis of the ISO/IEC 17799-1 Standard).

To meet these objectives, an effective IT security solution should be based on two points:

Clear security principles, algorithms and products based on time-proven designs; and
Independent, permanent verification and validation of the systems’ security features.

The first point defines the component quality used in the IT system, where a weak component may compromise the whole system. For example, a system that relies on conventional username/passwords for authentication is likely already broken.

The second point focuses on the need to continuously evaluate all potential and existing threats, and verify any additional security design features that might be necessary to mitigate the risks stemming from the most likely and/or most damaging threats associated with the customer environment, and eventual changes in that environment.

The ZSentry security solution satisfies both points. ZSentry uses standard encryption technology with the unique Sans Target method to keep it safe and HITECH Safe Harbor compliant to send data between parties as regular email. It does not require installation of any software, which is great for both security and usability, and it even adds functionality such as self-destruct, with message level access control. This is also good news for Novell users who have become used to this type of functionality.

For example, using ZSentry renders your private health data unreadable to any third party who might come across it, and takes the issue of HIPAA breaches and fines off the table.

Read more about Why Not Passwords?

Read more about End-to-End IT Security

Prevent Attacks and Improve Usability By Understanding Asymmetric Threats

2010-12-30T04:32:00.000-08:00

How asymmetric threats can blindside your organization, and how to prevent attacks supporting productivity.

Users are typically blamed as the weak link in security. Yet, we also need to take into account that users are often just naively reacting to asymmetric threats, that are difficult to evaluate even by experts.

Asymmetric Threat: a low-probability event with high-consequence.

The difficulty with preventing this type of threat is that even though the consequences could be disastrous (including collateral damage, information leak, and reputation loss), users may mistakenly accept the risk solely based on the event's low-probability of failure. As known in the medical field for an elective procedure called VBAC, many patients choose to undergo the procedure because the risk is low (say 1%), even though the consequence can be death or serious life impairments for both mother and child.

For example, in spite of all the attacks that we hear about on the Internet, it is known that the probability that any specific location will be successfully attacked is likely to be low for organization users. Consequently, users commonly see and rate online attacks as low-probability events ("Attackers will not guess my password.") and are not usually as concerned as they should be about the high-consequence side.

As another example, consider phishing. It is a typical asymmetric threat, where the user is asked to do something that seems safe (low-probability of failure) without realizing the high-consequences.

Users are unreliable security-partners to evaluate asymmetric threats.

Users tend to dismiss potential problems if they are perceived as low-probability events. Organizations, on the other hand, have to look more carefully also at what is at stake and the expected loss per event, which can capture the high-consequence risk and motivate adequate counter-measures.

Also important to many organizations today, for regulatory compliance with HIPAA and privacy regulations, are the potential high fines and breach notification duties that can be imposed, not just direct losses.

Usability and Security Aspects

Adding a conventional security system to better counter asymmetric threats and provide regulatory compliance, will most likely require users to change.

For example, if you must send to each recipient a password to allow reading the email, this makes it hard to use and is not natural. Or, if you must require recipients to register and select a password, just to read your email, this forces recipients to use yet another service they did not choose. Alternatively, if the solution requires going through a particular interface for webmail and/or install plugins for a desktop mail client, then users have to change their work environment.

Further, requiring users to change burdens users with new procedures and disrupts use when desktop updates and plugins clash, reducing productivity. This can also end up blocking cost-saving and desirable options, such as Google Apps and phones, if they are not protected.

Thus, notwithstanding the security and privacy needs, usability is also of critical consideration. Making it harder to use in order to be secure is not secure (either will not be used or be used poorly). Moreover, organizations have various non-compliant desktop, cloud, and phone systems that are in service and people already know how to use. There are other significant limitations in practice, such as non-compliant systems used by partners and customers, and customer support for new applications.

Users Do Not Want Change

If there is any unanimity in what users want, it is that they want to use their systems without change!

Second, users want to be able to switch to cloud or phone if they are not in the office, or if the office system is down. Third, users also want to communicate with their customers and partners without asking them to change. Fourth, users view security as "that which reduces productivity" and so will try to bypass security rather than follow a security process — for example, users will likely close a warning notice without even reading it.

The IT challenge today is how to provide the functionality that users want with the security that the organization needs.

The ZSentry Solution

To maximize return on investment, organizations should invest first in areas that support multiple objectives within a diverse spectrum of asymmetric threats. The goal is to effectively enable security and privacy compliance while assuring usability and versatility anywhere, for all systems that people can or already know how to use.

ZSentry is unique in providing these capabilities, through the various Use Options >> that can be used in separate or concurrently, including ZSentry On-Site (desktop Mail clients), ZSentry Cloud (FISMA compliant), ZSentry App (web browsers), ZSentry API (custom services), and ZSentry SMS (secure text messages for phones).

And given that no one is likely to successfully deter, prevent, or preempt every attack, organizations must invest in capabilities to help eliminate or at least mitigate the effects of a potentially catastrophic attack.

ZSentry is unique also in allaying access and data security concerns locally, in the infrastructure, and in the cloud. Each customer's login and data are protected in separate by the Sans Target ZSentry technology, with configurable, encrypted metadata (keys are also protected by the Sans Target ZSentry technology) providing a protected, standards-compliant, unique user experience and feature set for each customer.

This is even more important in the context of "cloud computing" and SaaS (Software as a Service), when user data may be stored in the "cloud". With ZSentry, customer access audit trails and customer data storage can be securely maintained in the "cloud" with encrypted, de-identified numbers, which access keys are provided and secured by the ZSentry technology.

Read more at Use Options >>

Inclusive Specialization with HIPAA for Desktop and Cloud

2010-11-26T20:13:00.000-08:00

With or without HIPAA compliance needs, your organization is likely facing two clear choices today: Desktop or Cloud.

The Desktop choice is interesting for business users, who commonly prefer to have their data local for privacy and control. In addition, Desktop systems such as Outlook are much easier for corporate setup and dealing with moderate to high mail volume, incoming or outgoing. And you can integrate data from different applications and different sources on the Desktop in ways that you cannot do with Cloud based solutions, such as in sending secure personalized messages merging each recipient's name and records.

On the other hand, with the Cloud choice, well-known systems such as Google Apps, Gmail, and Yahoo, offer easy access from anywhere, much lower cost (even free), 24/7 maintenance, and other benefits. But Google Apps, Gmail, Yahoo, and other Cloud systems are not HIPAA-compliant.

The Cloud choice privacy problem is solved by ZSentry, which enables Google Apps, Gmail, Yahoo, and other Cloud systems to be HIPAA-compliant. This allows the Cloud to be a good choice for Desktop replacement also in terms of HIPAA and privacy regulation compliance.

However, because each choice has good points (otherwise, would not be a choice), choosing also means losing.

This problem is also solved by ZSentry, which offers the On-Site setup, an inclusive specialization approach that works and is HIPAA-compliant for both Desktop and Cloud systems, as well as Web and Mobile systems.

With ZSentry there is no need to choose, and lose. Based on metrics that are important to your case, each choice can be specialized to areas where it performs best, such as in terms of cost, usability, and security. The same applies to email, webmail, IM, SMS, storage and other communication choices.

Rather than exclude valuable choices, the ZSentry Setup choices allow you to use each one where each performs best according to your metrics. And use the benefits of the Cloud platform also with HIPAA-compliant messages.

HIPAA-compliant Desktop and Cloud use is further discussed in the ZSentry On-Site use option, and you can try it without cost to see how it works for you. Other use options are available, including a HIPPA-compliant Cloud setup for Google Apps, that only uses a Web Browser.

Comments are welcome.

Identity Theft vs Impersonation Fraud

2010-10-21T12:47:00.000-07:00

If identity theft is a crime, mustn't identity be a property?

No. And, clearly, this should show that there is no such as a thing as "identity theft".

But why people, including laws in Congress, use Identity Theft instead of the long-established and legal term Impersonation Fraud? What's happening here? Was this just a change of fashion?

It's because language is being used to shift the burden to the consumer. Using the soundbite "identity theft", instead of "impersonation fraud", redirects the loss to the victim and frees those actually responsible from any legally relevant questions that could be asked about their loose security of customer's accounts.

"Impersonation fraud" as a term focuses attention on the fact that the criminal is deceiving someone in order to gain advantage by claiming to have some valuable characteristics or authorizations in fact belonging not to the criminal but to some other person. The person deceived is the primary victim in contemplation when this terminology is used.

"Identity theft", by contrast, suggests that the victim is the person impersonated, because his or her "identity" has been "stolen".

This way of looking at things implies that the losses which arise out of the impersonation fall on the person impersonated, rather than on the person deceived by the impersonation.

"Identity theft" as a label is attractive to, for example, some banks who may wish to suggest that losses must be carried by their customers because they failed to take proper care of their "identity".

Indeed, there is no such thing as an "identity theft" and there should be no responsibility to you if someone else uses your name and you do not know about it, in the same way that there's no responsibility to you if someone sends spam or mails a letter on your name.

The burden for preventing the real crime of impersonation fraud should fall on those who accept the false identity and also on those who do not protect private records of their customers. Certainly not the consumer.

If you feel that it is time to see real solutions to this problem, rather than let the discussion continue to be dominated by a special choice of language, What can you do?

Let's look at five key points that you should think of:

1. Think it through a bit more before considering to "buy protection". In fact, as discussed here, we should refuse to buy such "protection" and, instead request that those holding or using our identifiers follow the law and be held responsible for their misuse (as now enforced in the US with medical records) -- not the victims.

2. Note that the use of the term "identity theft" by an organization trying to sell "protection" against it to the very victims should be illegal. At the very least, it should alert us to that organization selling a service and then, in case of loss caused by that service, trying to pass both the blame and the loss to the victims.

3. The fact that people got used to talk in dumbed down soundbites such as "identity theft", instead of using well-established words like "impersonation fraud", does not mean that any legally relevant conclusions can be drawn from the misuse of technical terms like "theft" in the soundbite (as might be wrongly asked: If identity theft is a crime, mustn't identity be a property?).

4. Keep in mind that "identity theft" is not a theft, and the victim may not even have been remotely at fault, as in terms of negligence.

5. Do not allow loose language to redirect the focus elsewhere but where the problem really lies.

Now, how can you protect yourself against "identity theft"? What if your information falls into the wrong hands?

We increasingly communicate online instead of by telephone. Email, SMS and IM are the psychological equivalent of a voice conversation. People often forget, however, that a text message or an email conversation is stored online in many different servers and can be replayed many years later, often without the authorization of any of the parties, and often with undesired consequences.

According to a 2010 survey commissioned by Microsoft, 90 percent of the general population and senior business leaders are concerned about the privacy and security of their personal data in the cloud.

With ZSentry, you can actually eliminate the disclosure risk of email, webmail, SMS and IM by properly setting your message to self-destruct. This includes a combination of technical and legal measures, as done by secure email Zmail provided by ZSentry, and works with all editions.

Read more at http://zsentry.com/encrypt-and-self-destruct.htm

ZSentry Premium launch

2010-09-27T13:39:00.000-07:00

Anyone who was an early adopter of PKI (Public Key Infrastructure), PGP (Pretty Good Privacy) and other email security solutions will recall how difficult it was to explain how to send and receive secure email.

Secure email was one of those things that you couldn't really explain to people. It was something that senders and recipients had to see in action, something that they both had to learn and experience to really appreciate the way the technology would make their email secure.

Sending and receiving email is also one of those experiences that people just don't want to disrupt, not even to make it secure.

However, people more and more want to use email, webmail, SMS, and IM, and store documents online for easier access, while they also need to comply with HIPAA and other privacy regulations.

That's all solved with the commercial launch of ZSentry Premium in Oct/2010.

Since 2004, ZSentry has been in continuous use as a beta service and has served millions of secure email messages worldwide. ZSentry provides the needed security but does not change the way people use email or anything else, and works with desktop solutions such as Outlook as well as Gmail and Google Apps without plugins.

A fully-functional free version, called ZSentry Basic, will also continue to be available for personal use.

To see how it works, please explore the ZSentry How-To

While ZSentry can be provided on-site, it provides a convenient "pay-as-you-go" cloud service, where it innovates by eliminating critical security and privacy risks associated with cloud computing. Each customer's data is protected in separate by ZSentry's "Sans Target" ZSentry technology, with configurable, encrypted metadata (keys also protected by the "Sans Target" ZSentry technology) providing a protected, standards-compliant, unique user experience and feature set for each customer.

With its innovative design, ZSentry helps allay data storage security concerns, both locally and in the infrastructure. This is even more important in the context of "cloud computing" and SaaS (Software-as-a-Service), when user data may be stored in the "cloud". With ZSentry, customer access audit trails and customer data storage can be securely maintained in the "cloud" with encrypted, de-identified numbers, which access keys are provided and secured by the ZSentry technology.

Free Trial and other options are available.

Why you need to self-destruct your email

2010-08-21T11:26:00.000-07:00

Email, SMS and IM are the psychological equivalent of a voice conversation.

People often forget, however, that a text message or an email conversation is stored online in many different servers and can be replayed many years later, even without the authorization of any of the parties, and likely with undesired consequences.

The Internet "cloud", with webmail and more online processing services, just increases the privacy risks. According to a 2010 survey commissioned by Microsoft, 90 percent of the general population and senior business leaders are concerned about the privacy and security of their personal data in the cloud.

Your data privacy rights also vary in online versus local use (e.g., on an individual's USB token, or hard drive in the home or office), as well as "in transit" versus stored. Anyone familiar with the privacy limitations of current laws written in the pre-Internet era, such as the 1986 U.S. Electronic Communications Privacy Act, knows that the individual's legal rights to privacy and protection from unreasonable search are starkly reduced for information stored online. Data that individuals store online, in cloud computing services such as webmail, receives a much lower level of privacy protection than data "in transit" or stored locally.

Therefore, even though email may be the legal equivalent of a written conversation, email is mostly not legally protected online. That's one important reason to limit email liability. Other reasons include preventing harassment, coercion, blackmail, or just plain embarrassment.

But, how? An email message may live in many clients, servers, and repositories, some of which may be covert and unreachable by you and your ISP.

Surprisingly as it may seem, you can actually eliminate the disclosure risk of email by properly setting your email to self-destruct. This includes a combination of technical and legal measures, as done by secure email Zmail provided by ZSentry.

This is how it works.

ZSentry encrypts and self-destructs (expires, with no action on your part) your webmail, email, SMS or IM message, so that the intended recipients are allowed to read it only within its retention time, and neither you nor the recipients are responsible or liable for destroying it after it expires.

The command to expire is clearly noted and also provided with US and international legal support by notifying the reader that the message is copyrighted and that the sender only allows reading during its retention time. Therefore, if someone wants for example to take a picture of the message, then using that picture after the expiration could be considered a breach of copyright and illegal circumvention of protection. While the first motivation is to reduce exposure, the second is to provide a legal recourse in case of exposure.

After expiration there is no risk, as keys are deleted and any physical copy is therefore erased and not recoverable. Because self-destruct happens after a point in time that was known beforehand by all parties, claims of intentional destruction should be void.

What about before expiration? With ZSentry, you can request a Return Receipt so that any attempt to breach access security of your zmail is immediately logged and traced, and you can be notified as well by a Return Receipt that is sent to you with full access information including Who, Where, When, and How.

More information at How Zmail Works

Spam, Spoofing, Phishing, Pharming

2010-07-21T09:35:00.000-07:00

Are you concerned about email fraud, how to keep your message private, and avoiding identity theft? Do you think that people receiving an email attachment that was clearly sent from you (as stated in the From line) may fear opening it?

I frequently receive email from myself, that is with my name in the From line, that I never sent. It's well-known that anyone can send a regular email using your name and email address. This is used in spam attacks.

But, why should you care? "After all, it's just an email and I can simply delete it."

However, hidden persuaders in a message (or just in its Subject) may trigger your inadvertent reply to it, such as hearing that you are now listed in "The Internet Harvard Who's Who" (a fake honor), that your site can get a free evaluation (a scam offer), or an "alert" that someone is registering the left-most label of your .COM domain name in the Taiwan registry under .TW (which is legal and should not affect you). Or, and even more effective for the attacker, that triggers an irrational fear factor, where you fear things you shouldn't and then put yourself in greater danger. For example, a message from your bank, looking as the "real thing" and asking you to login to change your password.

So, as in many other cases, an initial, simple attack that is not checked can lead to secondary attacks with far more damaging consequences than originally thought possible.

What's gaining in importance in this space, although much less well-known than spam, is that attackers often use spam as a vector for delivering secondary attacks.

The most relevant secondary attacks today include not only spoofing, phishing, and pharming (see GLOSSARY), but also installing a "trojan horse", a computer virus, or crippling your computer with a ransom request to fix it.

Of these attacks, the most insidious and prevalent today is phishing, which can lure recipients to disclose their private data, that criminals worldwide (not necessarily just the attacker) can use to mount a real-world threat to your identity, bank account, and business, leading to potentially large losses. And criminals can do it all from an Internet cafe, somewhere in a far, far way place, or even next to you, and you (or the FBI) will not likely ever be able to hold anyone accountable for it.

How did we get to this point? Some think that the reason is that your email address is global and even searchable; that's why your mailbox is overflowing with spam. In short, one is led to think that there is no way to prevent it. You must fight it by purchasing solution X (a spam/spoofing/phishing filter), which will require frequent paid updates to be effective. But such solutions can only protect you against yesterday's attacks, and even that may fail as attacks have many variants.

Do I need to change my email address, Mail app, or provider, to be secure? No, the problems are not due to your email address or Mail app, but how you send and receive email. You should be able to use any email address, Mail app, and provider you want, including webmail.

How about if I add a firewall and always use SSL? Still, solution X (a spam/spoofing/phishing filter) will be killing good emails, and you really shouldn't open attachments even if you know the sender.

In addition, anyone can read any email that you send and receive, so that you cannot use regular email in HIPAA and regulatory privacy compliance. Regular email communication is simply not secure. Sending an email is similar to sending a postcard. Any regular email that is sent by you or to you may be copied, held and changed by various computers it passes through, as it goes from you or to you. Persons not participating in your email communications may intercept your communications by improperly accessing your computer or other computers, even some computer unconnected to any party in the communication, which the email passed or was made to pass through. That's also at the root of the spam problem. In the same way that anyone can send a postcard in your name, anyone can send a regular email using your name and email address.

NMA has developed ZSentry to protect your email against spam, spoofing and phishing emails, while adding a number of security and usability features that are missing in email, without changing your email address, Mail app, or provider. ZSentry also encrypts your email per-message, providing HIPAA and HITECH Safe Harbor compliance, as well as compliance with other privacy rules, with no Business Associate Agreement to be signed.

How does this work against spam, spoofing, phishing, and pharming? Rather than fight them, ZSentry prevents them by (among other features):

authenticating the source (including the sender's location) of a message; and
authenticating the name and email address of senders and recipients.

For example, if a Zmail (ZSentry Mail) comes to you from the email address <friend@isp.com>, and you can decrypt it using the ZSentry service, then you have strong, cryptographic evidence that it did come from that address as cryptographically authenticated during signup, with the original subject, date, body and attachment intact.

To read a Zmail, ZSentry also reminds users that they can copy-and-paste the ZSentry link (when, selected by the sender, Zmail uses an encrypted link). Rather than just click on the link, this simple procedure prevents users from landing at a destination that was encoded in the email to be different from what users can read on the screen before they click.

Users can also beneficially apply a spam/spoofing/phishing filter prior to reading the Zmail, to reduce input email volume. However, the filter no longer has a critical, final function. This also means that the filter does not have to be set so tight as to increase too much the number of false positives (the number of rejected but good email), or should one fear that the filter is letting through too many false negatives (the number of accepted but bad email).

A further benefit of the ZSentry approach is that it does not require the customer to update anything in order to remain protected.

Other approaches (solution X, a spam/spoofing/phishing filter) such as those based on email headers, reputation, non-verifiable metrics (eg, community detection), blacklists, pattern detection, heuristics, zombie detection, and message scanning, can break privacy and may easily fail. One of the reasons to fail is that spam and phishing emails are created in an arms race scenario, where defenders lag behind with less knowledge and resources and are often fighting (perhaps, even well) the last exploit but not the next. Exploits are also hard to filter because they have many variants, spoof various parts of email headers and body, and come in the name of people or organizations you trust — your friends and business contacts. You probably receive several emails from yourself (surely, it is a valid email address and one that belongs to a real, reputable person) that you never sent.

Training users to detect spam, spoofing and phishing adds costs and also frequently fails, as users cannot be trusted to follow procedures, are easily distracted, and may not understand the instructions in the first place. ZSentry does not depend on users learning ever-changing patterns, as this is one of the few things that is actually proven not to work, or just work poorly.

How about spam? ZSentry also has a zero-tolerance spam policy. There are several mechanisms in place to prevent any ZSentry user from abusing the system and sending Zmail spam. For example, ZSentry BASIC users can send a limited number of secure email Zmail messages a day. ZSentry PREMIUM users, who must provide a valid payment information and physical address in order to use the service, are allowed to send larger amounts of secure email.

GLOSSARY

What is a "spoof web site"?

A spoof website is one that mimics another website to lure you into disclosing confidential information. This can be done even with SSL (Secure Sockets Layer) using 128-bit encryption. To make spoof sites seem legitimate, spoof web sites use the names, logos, graphics and even code of the real company's site. They can even fake the https web address that appears in the address field at the top of your browser window and the "SSL padlock" that appears in the lower right corner of your browser.

What is a "spoof email"?

A spoof email has the "From:" header of the email, and possibly other headers as well, set to the email address of a different sender, to lure the recipient to read and act on the email. For example, using the email address of a friend, a legitimate company, a bank or a government agency. This is very easy to do with regular email. To make spoof emails seem legitimate, the email body uses the names, logos, graphics and even legitimate web addresses and email addresses in some fields. The action links in the spoof e-mails almost always take you to a spoof web site. Spoof emails can be sent also as an attack against you or your organization, with fraudulent offers, bogus announcements or malicious content.

What is a "phishing email"?

Phishing (or hoax) emails appear to be from a well-known company but can put you at risk. Although they can be difficult to spot, they generally ask you to click a link back to a spoof web site and provide, update or confirm sensitive personal information. To bait you, they may allude to an urgent or threatening condition concerning your account. Even if you don't provide what they ask for, simply clicking the link could subject you to background installations of key logging software or viruses. Every business on the Internet is a potential victim of phishing email attacks, eroding the trust of their customers in the company's communications.

What is "pharming"?

A pharming attack redirects as many users as possible from the legitimate website they intend to visit and lead them to malicious ones, without the users' knowledge or consent. A malicious site can look exactly the same as the genuine site. But when users enter their login name and password, the information is captured. Emailed viruses that rewrite local host files on individual PCs, and DNS poising have been used to conduct pharming attacks. Even if the user types the correct web address, the user can be directed to the false, malicious site.

What is "spam"?

All Internet users should by now know about spam. The word spam as applied to email means Unsolicited Bulk Email. Unsolicited means that the recipient has not granted verifiable permission for the message to be sent. Bulk means that the message is sent as part of a larger collection of messages, all having substantially identical content. Usually, a message is spam if it is both Unsolicited and Bulk. Unsolicited email is usually normal email (examples include first contact inquiries, job inquiries, and sales inquiries). Bulk email is usually normal email (examples include subscriber newsletters, discussion lists, information lists, and update announcements).

Comments are welcome.

White House Seeks Comment on Trusted ID Plan

2010-06-26T11:41:00.000-07:00

It's important to protect privacy! This is a comment on a federal draft plan calling for the U.S. government to work with private companies to create what the White House Blog calls The Identity Ecosystem — an online environment "where individuals, organizations, services, and devices can trust each other because authoritative sources establish and authenticate their digital identities," also called "The Trusted ID Plan".

Introduction

Some have said that The Identity Ecosystem proposal is a call for a mandated Internet "driver's license". Others believe that The Identity Ecosystem would allow Internet users to complete transactions with confidence.

Our opinion is that while it could be the former, it cannot be the latter as it stands.

We are, thus, motivated to present this proposal, which supports the objectives of The Identity Ecosystem without adding any form of central control (or even fear of), while it allays privacy concerns, especially online. Further, it can be easily commercialized using an ecosystem with open participation, and internationalized, without any changes in current laws, which many privacy advocates argue do not sufficiently protect privacy online in the US and elsewhere.

How Did We Get Into This?

Before we present our contribution, we would like to invite us all to step back and ask "How did we get into this?"

Accounts may vary somewhat on how the Internet came to be what it is today. However, our exposition will not start controversially. We will stay on undisputed facts in terms of authority and authoritative sources in the Internet, which is quite central to the The Identity Ecosystem proposal.

Starting with the transfer of responsibility and authority for Internet policy increasingly from DARPA to NSF and to the Federal Networking Council after about 1988, NSF's role increased substantially with the creation of the NSFNET.

At that time, central control of the Internet as initially provided by DARPA was effective, as evidenced by the fact that spam was famously not allowed and did not exist.

But as the transfer process from DARPA continued, the central control paradigm started to change and weaken. Other points can also be mentioned, such as the role played by BBN in showing that it could work, and the gradual decrease of NSF's role to the point were the NSF was prohibited from spending money on it. And, on October 24, 1995, the Federal Networking Council famously passed a resolution defining the term Internet.

Of course, control did not evaporate immediately after 1988 or even 1995. As control was relaxed, fear of control remained for a long while, as shown in Dr. Jon Postel's famous failed attempt to relax control by redirecting Root to the IANA (Internet Assigned Numbers Authority) on Jan. 28, 1998.

This is the big picture that matters now, in 2010. From 1988 onwards, the US Government has deliberately relaxed its control over policy as the Internet has become increasingly commercialized and internationalized. Hence, gradually, confidence has evaporated because it was based on that, now missing, central control.

This is how we got to be where we are, by the very nature of growing into and being a network of networks, where no one can control both ends of a general communication channel (neither sending nor receiving).

The Internet, Confidence, and Trust

The Internet was born within a strict central control system (DARPA), but then it grew and now (as we saw above) abhors central control. This development was enabled by technology, allowing networks of networks to be easily built and expand. However, it is not unlike what we find elsewhere. It seems to be a natural process, and not one that we can reverse (or should try to reverse).

If central control cannot be restored, how can confidence be restored? How can rogue operators be detected and prevented from using protected resources?

The word confidence means "with faith". It is a good concept to use when we can have an authoritative source (e.g., DARPA). But fails miserably when such source does not, or cannot exist.

In such cases, we can use a concept called trust that has been intuitively known for thousands of years. Trust has been formally defined (Gerck, 1998) in terms of Information Theory, as "trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel".

This is an implicit definition, allowing us to derive many equivalent positive and negative statements and use them as "domain definitions", so that we can use the concept of trust coherently through different domains including with people and machines. See http://bit.ly/TRUST and http://bit.ly/IT-TRUST

For example, the definition implies that a decision to trust someone, the source of a communication, the name on a certificate, or a record must be based on factors outside the assertion of trustworthiness that the entity makes for itself.

As another example, in terms of a conversation, we can use the equivalent domain definition (see references) "trust is that which provides meaning to information". Indeed, according to the trust we have on the information source, the same words may have quite different meanings -- as it can be easily demonstrated by watching the different meanings presented in newscasts by FoxNews and MSNBC, for the very same information.

The important point here is that trust can be based on other factors, in addition to control or even fear of control.

Solution Considerations

A solution to the perceived identity problem in the Internet should, thus, investigate what other factors must now be introduced in order for trust to be induced without trying --and failing-- to re-introduce control, or fear of control.

In other words, there's no "Doomsday" scenario of control vs anarchy either way. Rather, there are many reasons to abandon the mindset of recourse to control (or fear of) as the only solution.

For example, we need to take into account that the Internet is essentially open-ended. Anyone can join some network connected to networks comprising the Internet. The Internet is a network of networks, with no common reporting of any kind that could allow objective authorizations to be authoritatively defined and enforced, for all the different networks in the Internet.

We also share the same network as the attackers. Even if all identities were somehow centrally controlled, the false use of identities would not be preventable (as we know well from the brick-and-mortar world, for example). This further indicates that we shall not hope to be able to confine what we cannot control.

Users, furthermore, are bound in their defenses by their own usability and resource limitations, and service providers must only deploy defenses that users may tolerate. This creates an "arms race" scenario with a large information and power asymmetry against users. Attackers know more and are much more powerful than users and even service providers, and can rather easily mount massive campaigns with massive resources (e.g., a phishing attack using thousands of bots), while defenders are frequently one step behind with the defenses they can deploy.

It would, therefore, be better for users that we avoid an "arms race" scenario, where defenders (users) will lag behind. Instead, we motivate the need to find ways and "methods of peace" in achieving Internet security, where security must be primarily viewed as a form of understanding, not of confinement or subjugation. For example, it makes little sense to confine use to X, if one has no justification to trust that which one is using in order to confine use to X or, if one does not know what one is confining in or out.

Thus, unless we are conditioned to think that the only way to effect security shall be by subjugation and fighting the "thing" out to the bitter end, which will mean the defeat of users and their rights, we should not pursue control (or fear of) as the only solution. It does not fit the problem and does not help users.

And the main visible point to users should be about how to make non-conformance public rather than certifying conformance.

Not only would there be then much less liability for the service, but the user is kept in the verification loop --as the user should be-- rather than blindly rely on some sort of oracle. Also, in security terms, not only less attacks are possible but attacks are so not direct in creating an error condition. This does not mean that the user would manually have to make the determination in every case and be burdened by it. The non-conformance detection can be automated, classified by risk, cached, and previous results can used until they expire according to their respective risk class.

Along these lines, identity should not only refer to an attribute (name) or some aggregation of attributes (name, address, SSN) but, even more strongly and effectively refer to relationships ("Is there an identity relationship between the true owner of this Mastercard and the person presenting it to me?"), connections, absence of connections, and other connection properties. It's not about one authoritative channel either, to vouch for the identity, but using multiple factors to prevent a single point of failure.

Privacy Rights

Let us think about the US Government getting involved in assuring identity and protecting privacy at the same time. I'd like to mention Judge Scalia's private (but not secret) comment to a previous team member, who had an opportunity to speak with Justice Scalia in 1999, and asked him if privacy warranted strong legal protection in the US. Of course, this would be at least tangentially relevant to any US Government identity initiative such as the Trusted ID Plan.

"Not based on the constitution", Scalia said. "Nowhere does the constitution address the right to privacy. If people want the Right for Privacy, they will have to change the constitution."

More importantly, Scalia added that "Free Speech is defended by the constitution, and that makes the Right for Privacy very difficult to defend."

The Scalia quotes are as verbatim as memory can allow, are not jurisprudence, and other Justices may disagree, but the idea is quite easy to verify — the US Constitution does not support the Supreme Court to rule in favor of privacy rights purely on constitutional grounds and could deny privacy rights in the event of a clash with the well-established constitutional right to freedom of expression (by a person or company).

In other words, it is possible that a company's right to freedom of expression (as in the recent election spending Supreme Court decision) would trump an individual's right to privacy.

It is further well-known that users' online privacy rights are reduced in the US by the 1986 Electronic Communications Privacy Act (ECPA), which is complex and often unclear. What is clear is that the ECPA does not mandate a search warrant to access online private communications and the locations of mobile devices. Data or files stored in the Internet "cloud," such as webmail or identity data, are subject to an often lower privacy standard than the standard that applies when the same data is stored on an individual's hard drive at home or in the office.

Considering also the lack of privacy protection in many US States' constitution (except, for example, California and Washington as examples where privacy is strongly protected by their constitutions), and in the US Constitution, in addition to the well-known information asymmetry problems and other aspects (e.g., power asymmetry) that are behind the increasing market failure to protect users' privacy in the realm of private companies, as well as lack of international harmonization in this regard, the conclusion is clear:

Currently, we should be careful in relying on government, market (private companies), or legal recourse to protect users' identities.

Thus, a missing and yet important part of The Identity Ecosystem proposal in this matter should be on helping to improve laws regarding identity and privacy, which will facilitate the adoption of useful technologies.

How about The Identity Ecosystem?

Based on the discussion above, both technically and in terms of privacy protection, it will not work to have the Internet fall back to the idea of confidence supported by authoritative sources that would purportedly "establish and authenticate users' digital identities". Central control, and fear of it, is both not possible and not privacy-preserving.

Thus, if we think of it in terms of a "Trusted ID Plan" supported by authoritative sources, it will be restricted in use to those authorities each user can trust (and, likely, pay) within their own desired extent, which varies for each user, each case, and also over time and location. This will likely lead to a number of disjoint local systems that will not be able to talk to each other or internationally.

However, The Identity Ecosystem may use a more comprehensive approach.

Many real solutions are possible, but they should all be founded on the idea that trust can be based on other factors, in addition to control or even fear of control. For example, a user should be able to effectively refer to relationships or just even prior communication established online with other entities, in defining an assertion of identity. A solution should, thus, investigate what other factors must be introduced in order for trust to be induced.

In so doing, we point out that self-assertions cannot induce trust (http://bit.ly/IT-TRUST). Saying "trust me" should not make you trust me. The verifier needs to have access to multiple and varied sources of trust channels.

Further, to be usable, we want to reduce user frustration in having to use a different tool if one needs security and regulation compliance. This also would help reduce the focus on security, so that people can long at last focus on what they want to do, not how they have to do it.

A Definite Proposal

In addition to the considerations and suggested guidelines above, I also submit a definite proposal, that has been field-tested in millions of cases in the US and worldwide since 2004, and can be demonstrated today, to anyone, with zero cost.

The author, based on the ideas of trust developed earlier (Gerck, 1998, op. cit), has developed a protocol that fits the above considerations, provides multiple and varied sources of trust channels, does not rely on "trust me", and yet provides a "no target" approach to eliminate concerns of attacks stealing identity credentials in online servers. It is the "identify & authorize" engine, as used by ZSentry.

ZSentry is available without cost for personal use (Free Basic) and can be used with mail, webmail, file transfer & storage, IM, SMS, HTTP, fax and other communication protocols. ZSentry supports the ZS authentication mode, as well as PKI/X.509 and PGP. ZSentry also extends these standards in significant ways. An important issue solved, of course, is the problem of initial contact. ZSentry allows secure first contact and reply without previous interaction (e.g., exchanging passwords, requiring registration) or work (e.g., searching a directory, solving puzzles), and provides a number of life-cycle control functions, including release, expiration, and delivery verification.

ZSentry also supports SAML and SSO, so that it can be part of a federated-identity ecosystem. And you do not have to worry about your identity being stolen online at the ZSentry site, or at other sites you visit. ZSentry uses its "no target" technology to protect your login credentials and keys at ZSentry, whereas the SAML identity authorization does not carry them either.

Preventing false login (eg, by stealing a user's credentials with a key-logger) and duplicate use of the same account, may be a threat in some cases, especially with SSO. ZSentryID can be used to introduce a fresh second-channel challenge that changes for every authentication, for example by cell phone SMS. ZSentry also uses Adaptive Security, and other techniques to help allay such concerns.

The trusted introducer function provided by ZSentry does not need to be carried over forever. This is not a single provider, lock-in proposal.

Much like a booster rocket, once the transaction starts, other sources of trust are introduced (e.g., who do you know that I trust and can verify you by? What is your signed library key?) to the point that the ZSentry introducer function can be jettisoned without prejudice.

With our proposal, there is no "trusted ID" that will suddenly lose all its evidence value if not renewed.

Technical information on ZSentry identity verification is available at http://zsentry.com/identity.htm

I submit that ZSentry supports the objectives of The Identity Ecosystem without adding privacy concerns, especially online where it's not a matter of if but when and how often information on servers (even hosted at the Pentagon or FBI) will be disclosed.

Best regards,
Ed Gerck

It's important to protect privacy! You can vote on our proposal if you wish at: http://www.nstic.ideascale.com/a/dtd/The-ZSentry-Proposal/45785-9351

Cloud security

2010-05-14T10:10:00.000-07:00

Some people say that cloud security comes down to this simple question:

Do you have 24/7 unrestricted access to the PHYSICAL machine where your data is stored?

If no, then your DATA IS NOT SECURE.
If so, YOUR DATA MIGHT BE SECURE.

This line of questioning goes to the heart of most security problems, and not just in cloud security terms.

To further an example, rather than requiring a key to open a door (metaphorically, to access a data file), more secure systems would require 2, 3 or N keys such that a subset of M keys (for example, 3 out of 5, where N=5 and M=3) would be required to open the door. So, even if you lose the key in your pocket, or someone takes it from you under gun threat, you still have security within M of N. This is usually called a "security quorum" or "threshold system".

Useful as a threshold system may be for cloud security, is there still room for improvement?

A major improvement would be to eliminate the root of trust (i.e., that which you rely upon to assure that the threshold system and keys work as intended) [1] so that there is no target to attack. The principle is that no one can attack what does not exist. Not only a security quorum would not be needed (which can improve usability and prevent a denial of service attack) but also complexity would be reduced.

This solution, which is implemented in NMA ZSentry [2], effectively shifts the information security solution space from the yet-unsolved security problem of protecting servers and clients against penetration attacks to a connection reliability problem that is easily solved today.

Thus, in terms of cloud security, you can set up layers upon layers of security, but this is all for naught if the root of trust lies within the cloud itself. You solve this problem by eliminating the root of trust inside the cloud, as done by ZSentry, which is available free for tests and personal use [2].

This is important not only for health care records for HIPAA compliance, and privacy regulatory compliance in general, but also for individuals. Email, SMS and IM are the psychological equivalent of a voice conversation. People often forget, however, that a text message or an email conversation in cloud storage (such as in gmail, yahoo, hotmail) can be replayed even many years later, often without the authorization of any of the parties, and often with undesired consequences.

In perspective, while it may not be reasonable (or cost-effective) to assure that you have 24/7 unrestricted access to the PHYSICAL machine where your data is stored, you can use methods that deny the existence of the root of trust within the cloud itself. The cloud should only be used to store de-identified, encrypted data, and without the keys that would allow the data to be unraveled.

[1] For the formal definition of trust, that applies to both computers and humans, see http://bit.ly/TRUST

[2] http://zsentry.com

Bank of America's SafePass Security: strike out

2010-04-26T17:10:00.000-07:00

(Posted online by Joel M Snyder. The problem and description are particularly relevant in our security and usability studies of access control systems.)

Bank of America lets their patrons sign up for "SafePass," which is a credit-card-sized one-time password device. You MUST sign up for SafePass for certain transactions (like large transfers) but it is optional for most customers.

I signed up. Much to my woe.

The sign-up fee for the card is $20.

I got my card, and it's physically defective: no number shows up when you push the button.

To get this problem remedied, Bank of America has me in an infinite loop. The phone people cannot send me a new card (why? I don't know). So I am supposed to do this through the web site.

However, once you have signed up for SafePass, you must use your SafePass to make any changes to SafePass (including getting a replacement card, and let's not even start on whether or not it's going to cost me another $20 to get a replacement for the first defective card).

So I was transferred from customer service agent to customer service agent, and each one assured me that they need to get this card activated. Some thought that if they activate it on their end, through the miracle of the ether, this will suddenly cause numbers to show up on my display here. (Attempting to explain that this could not work turned out to be a losing battle). I went through supervisors. I went through supervisors to supervisors.

In the end, the "solution" that they came up with--after 55 minutes on the phone, mind you--is that I should order a new card (not a replacement, which I cannot do, because the current card cannot be activated, but a new card, as if I need two of these things). They agreed to make a $20 credit on my account, and this will then add up to solution required.

And all this because I was trying to do "the right thing..."

jms

Red Flags In Email Security

2010-03-27T12:37:00.000-07:00

REQUEST FOR COMMENTS: This article is based on a work draft submission by Ed Gerck, Ph.D. and Vernon Neppe, MD, Ph.D. -- your comments are welcome.

Solutions for email security are often plagued by hidden costs, hidden liability, and lack of both security and usability. Even though the choice of a security solution involves many aspects, what is clear is that a selection process should not overlook some obvious red flags.

Red Flag #1: Sign a HIPAA Business Associate Agreement. This means that the security solution is exposing you to unnecessary technical, business, and legal risks.

Signing a HIPAA Business Associate Agreement is mandatory if the solution does NOT take advantage of the HIPAA "Safe Harbor", which requires encrypted and de-identified data. In addition to legal model and harmonization problems for you in signing another contract, absence of the "Safe Harbor" means that if a breach of unsecured protected health information (PHI) is discovered, fines may be levied and notices to each person affected are required. In addition, contracts with a "Covered Entity" may be at risk and the reputation of all business involved will almost certainly be harmed.

Red Flag #2: Centralized directory for email encryption. Someone other than yourself has your business partners' and customer's contact information, with names, email addresses and other data.

In addition to being a single point of failure, this means that your data may become available or be sold to solution providers and other businesses. This also means that in the event data is lost or stolen, it is linkable to a particular person, at risk of violating HIPAA, HITECH, and other regulations.

Red Flag #3: It Just Works. Beware of hidden liabilities. For example, make sure that your keys are not escrowed in the servers providing the solution, as with IBE (Voltage). Nothing is safe in servers, not only from attackers but also from service providers and employees.

Red Flag #4: Key Management "in the cloud". Beware that nothing is safe "in the cloud".

Customer data storage, including keys, can only be securely maintained in the "cloud" with encrypted, de-identified numbers, where the access keys should be provided and secured by yourself. See also comments to Red Flag #16.

Red Flag #5: Service automatically detects and encrypts messages that contain personally identifiable information. This means that your service provider actively stores and scans all your communications.

Also sometimes mentioned as a "hosted solution that automatically encrypts email based on your policy definitions". This not only falls within the Red Flag #1 and excludes a "Safe Harbor", but potentially exposes your business to covert surveillance as well as to legal loopholes allowing service providers to use and sell your information as it is not "data in motion".

Red Flag #6: Ensure Business Associates understand HIPAA implications. This means that your business risk and reputation depends on others, who you cannot control. Instead, your security solution should limit the risk posed by others.

Red Flag #7: Keys provided by "Web-of-Trust". This means that there is no entity responsible for revocation of keys, or for assuring that the keys are up-to-date, or valid for the intended purpose. This may work with a group of friends, but not when your risk and reputation depend on it.

Red Flag #8: Require Users to Buy a X.509/PKI or S/MIME Certificate. For a variety of reasons, and not just cost, this has not worked since it was first proposed more than twenty years ago.

Red Flag #9: Protected with passwords. Passwords are notoriously insecure and their management is a nightmare even for a few dozen users.

Passwords are not considered secure by HIPAA, HITECH, the Federal Financial Institutions Examination Council (FFIEC), and other regulatory regimes. Compliant authentication solutions should use two-factor authentication, present familiar user interfaces (to prevent user errors), prevent dictionary attacks, and not store authentication credentials (such as passwords and usernames) online or, more desirably, anywhere.

Red Flag #10: Use the fax. It is a privacy and HIPAA violation to allow faxes with personal information to be available in an office area that can be accessed by anyone other than the intended recipient, which is also notoriously difficult to ensure.

Red Flag #11: Our employees are trusted. Your business data security should not depend on trusting the service provider's employees ("we promise we won't look"), who you cannot select, verify or control. It is known that more than 70% of all security breaches are due to internal causes. Not even the FBI can prevent having a national security traitor for many years among their own directors.

Red Flag #12: We train your employees. This means that your employees will need to be trusted to follow security procedures, which failure will fall on your business and is at the root of more than 70% of all breaches. See Red Flag #11.

Red Flag #13: Just install a plug-in for your Mail client or Web browser. Also mentioned as "downloaded and installed in minutes". This means that you have to download an untrusted new component, that opens your system to new zero-day exploits, will need to be always updated, and may cease to work when you update your application or other plugins.

Red Flag #14: Delivered using a secure SSL/TLS encrypted connection. This delivery process falls short of basic security requirements for email messages (see references below). See also Red Flags #1 and #5.

Red Flag #15: If the recipient is not registered, the message is sent to a secure portal. This means that the recipient must register anyway, and reduces usability.

Red Flag #16: We can use your information for purposes including... This statement may sound assuring but it is open-ended and does not exclude any purpose or person.

This Red Flag is actually worse than the notorious "opt-out" policy, where sharing your protected information is the default mode, as there is no limit that you can request (by opting-out) regarding the use of your protected information.

Red Flag #17: Beware of conflicts of interest between the distinct roles that may be played by the same service provider, which may increase both your risk and liability. Also called the "fox taking care of the hens" scenario.

For example, if (1) a service provider for secure email is also (2) a provider of anti-virus scanning service, then the service is potentially made aware of protected information and the "Safe Harbor" provision may not apply (see Red Flag #1).

Red Flag #18: Impossible to break. Our servers are in a secure facility. It is not a matter of if, but when.

Regardless of how safe and secure people claim something online is, there always seem to be someone who can eventually crack access to it. Not even US Department of Defense and Pentagon servers are secure.

Security claims should not depend on being "impossible to break" (the Fort Knox approach), but on the impossibility of finding anything of value when that happens. This strong concept of security does not assume any limitation on the attacker, which limitations are often found to be unrealistic but only after an attack succeeds.

Regulatory Compliance and Fines

These and other Red Flags are important because security and email encryption are gaining importance, for some very clear reasons:

Email phishing, spam, email disclosure, and identity theft are major sources of fraud losses today.
Protecting consumer privacy is becoming a duty for organizations worldwide.
Organizations in regulatory privacy and security compliance regimes (e.g., HIPAA and FFIEC) need to communicate in a way that is compliant.
After 02/2009, fines for non-compliance (HITECH Act) have sharply increased up to $1.5 million.

For example, in the health-sector, service providers must comply with the US HIPAA (Health Insurance Portability and Accountability Act), HITECH Act (Health Information Technology for Economic and Clinical Health Act of 2009) and other regulations.

Conclusions

The choice of a security solution involves many aspects, including not to overlook the 18 red flags we discuss in this article. We also observe that privacy and security compliance is not enough — any security solution must be, first and foremost, usable. Otherwise, it will not be used or used incorrectly, defeating the security objective.

References

Gerck, E. (2007). Secure email technologies X.509/PKI, PGP, IBE and Zmail. In Corporate Email Management, Chapter 12, Edited by Krishna SJ, Raju E., pp.171-196, Hyderabad, India, ICFAI University Press. Available online at http://email-security.net/papers/pki-pgp-ibe-zmail.pdf.

Neppe, V. M. (2008). The email security-usability dichotomy: Necessary antinomy or potential synergism?. In Telicom, 21:3, May-June, pp.15-31. Available online at http://email-security.net/papers/usable-secure-email.pdf.

Whitten, A. and Tygar, J. D. (1999). Why Johnny can't encrypt: A usability evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium. Available online at http://www.gaudior.net/alma/johnny.pdf

Feghhi, J., Feghhi J., and Williams, P. (1998). In Digital Certificates: Applied Internet Security. Addison-Wesley, ISBN 0-20-130980-7.

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

2010-02-24T20:45:00.000-08:00

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:

claims processor;
provider of patient EMR to their pharmacies and doctors;
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

SSL would prevent it, Re: Internet security flaw exposes private data

2010-01-17T12:14:00.000-08:00

We all read about the most recent Internet security flaw that exposes private data [1]. Without any action on their part, a number of AT&T smartphone users found themselves logged into Facebook, a popular social networking site, under user accounts other than their own. The problem was quickly attributed to "misrouting," a term that suggests that information took a wrong turn somewhere in the network.

It looks like AT&T did something wrong, but in terms of proxy server setup, not routing, and the company is in the process of fixing it. But Facebook should also share some concern with this, as it didn't consider the information tied to a user's account authentication to be important enough to protect with something stronger than clear text.

So, when we look closer, the sky is not falling.

With at least one authenticated end-point (the end-point server, as usual), SSL would NOT allow an AT&T caching server that sits in-between to have had a "correct" SSL session between the wrong two end-points. See A. Menezes et al., /Handook of Applied Cryptography/, CRC Press, New York, 1997.

This statement is true even if the AT&T caching server is able not only to modify packets but also to drop incoming packets and insert its own packets at will into the traffic, and do so in two-way communication without delay, becoming an active man-in-the-middle (which a passive, caching server is not).

This should not be confused with a phishing attack, where the end-user is tricked to go to (for example) paypal.fraud.com instead of paypal.com -- and the server end-point is already wrong, or a "bridge" attack where (without noticing it) the user goes to the wrong server before SSL starts -- and stays there after SSL starts. The second user did reach facebook.com and this would have been enough under one-point authenticated SSL to prevent the first user session to be hijacked (which is what happened) as it would not have the correct session keys.

This should also not be confused either with other attacks on privacy and security, that work in spite of SSL. For example, if SSL is used you may still be connected to the wrong site (eg, using a rogue certificate), and your traffic may still be read by others behind an SSL proxy, but you would not be connected to someone else's previous SSL session, not would your SSL session be usable by someone else.

These attacks, despite much confusion online in discussion lists [for example, see refs. 2 and 3], do not break SSL nor have any bearing on the SSL being able to prevent the reported facebook case ("Internet security flaw exposes private data").

The AT&T problem that originated this security issue -- which, by all evidence, was not an attack -- would have been prevented by facebook requiring SSL. This may be particularly important for mobile devices,
where users may have less connection information available to verify.

And, google did the right thing now by making SSL the default for gmail.

REFERENCES:
[1] http://arstechnica.com/web/news/2010/01/facebook-att-play-fast-and-loose-with-user-authentication.ars

[2] http://www.listbox.com/member/archive/247/2010/01/sort/time_rev/page/4/entry/13:270/20100117153354:9FD73A7C-03A7-11DF-8606-4E77A52306B0/

[3] http://www.listbox.com/member/archive/247/2010/01/sort/time_rev/page/4/entry/11:270/20100118113841:EE029CD4-044F-11DF-868D-868DA52306B0/

Why don't people use certificate-based access authentication?

2009-12-19T09:53:00.000-08:00

Most systems still only offer username/password authentication, and most people are still happy to use it, even though everyone knows (for example, through daily media headlines) that there are pervasive user access security problems with it.

Why don't people use certificate-based access authentication?

This question is important for email security and also in other areas, such as web site and blog access.

We suggest that a proper answer requires thinking that has to be much more nuanced and sophisticated than just a discussion of usability versus security.

Such thinking should come also from analyzing online and offline feedback, as we need to approach the question as it is seen -- from many sides.

We have taken this approach in our paper, now updated, at http://email-security.net/papers/takefive.htm

Please provide your comment. You can also Read the Compact Version

Thank you!
Ed Gerck

Let's "Take Five" In Internet Security

2009-11-13T11:34:00.000-08:00

With everything that is happening (and not happening) in Internet security today, and all its complexity, it is perhaps useful to stop our busy day and take a little time out to start a conversation and question a couple things.

The worst Internet security problem for users today is not email or even about email, however it deeply affects email security. We are talking about the security and usability of Internet user access control systems. This problem is well-known but we meekly accept it "as it is" everyday.

But the paradigm may shift in five minutes. We find that, surprisingly, to tackle this problem we just need to take five minutes to go over five frequently asked questions. And that is our invitation to read the paper and provide your comment at http://email-security.net/papers/takefive.htm

You can also Read the Compact Version

Thank you!
Ed Gerck

Discussion summary on improving SSH

2007-07-19T16:42:00.000-07:00

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

Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-27T16:08:00.000-08:00

...

I personally would prefer to sign every email I send. I'd also
prefer to encrypt all non-public messages. I am fully competent
in the use of the current technology, but it turns out to be not
practical to use.

Greg

Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-27T16:02:00.000-08:00

Paul Hoffman wrote:

This is my original disagreement with Ed's message. It can be done, and when you do it it works, but it is too difficult for most people to bother with. I think we all agree on those three facts, just not on what to label the last one.

Actually, when I wrote "it does not actually work" I meant all three things:

1. It can't be done as a user would like to do it; note also that even experts
do it incorrectly (it's just too many detail devils).

2. When a user does it, the user does not really know if it was done right.

3. It is too difficult for users to use and (worse) most users who use it
do it incorrectly.

We have some choices. We can continue to say that it works and just wait
for users to get educated someday. Or, we can say that there is no x (x = market,
need, risk, point) -- and that's why no user bothers with it. Or, we can try
to understand what's it that users reject and work around it. My opinion I
already say upfront: users reject the whole model; it's not "natural" to
ask me for my envelope before you can send me a letter.

(btw, name and mail address are not the envelope -- they are routing
information. My public-key is the envelope analogue when comparing postal mail
with secure email.)

Cheers,
Ed Gerck

Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-27T15:54:00.000-08:00

Phil Z doesn´t know how to do it himself, at least with PGP.
He told me that he doesn´t sign people´s keys who ask for it,
simply because it would pollute his keyring on his computer,
and he couldn´t work with a keyring with thousands of people
on it anymore.

So PGP obviously has a usability and scalability problem.
So he only signs the keys of his friends because of that.
I wonder now, why he didn´t tried to solve that
usability/scalability problem himself yet, but gave up instead.

Best regards,
Philipp Gühring

Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-27T15:51:00.000-08:00

Paul,

Usability should by now be recognized as the key issue for security -
namely, if users can't use it, it doesn't actually work.

And what I heard in the story is that even savvy users such as Phil Z
(who'd have no problem with key management) don't use it often.

BTW, just to show that usability is king, could you please send me an
encrypted email -- I even let you choose any secure method that you want.

Cheers,
Ed Gerck

Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-27T15:49:00.000-08:00

Ed Gerck wrote:

This story (in addition to the daily headlines) seems to make the case that
the available techniques for secure email (hushmail, outlook/pki and pgp) do
NOT actually work.

That's an incorrect assessment of the short piece. The story says that it does actually work but no one uses it. They briefly say why: key management. Not being easy enough to use is quite different than "NOT actually working".

--Paul Hoffman, Director
--VPN Consortium

NPR : E-Mail Encryption Rare in Everyday Use

2006-02-27T15:24:00.000-08:00

This story (in addition to the daily headlines) seems to make the case that
the available techniques for secure email (hushmail, outlook/pki and pgp) do
NOT actually work.

http://www.npr.org/templates/story/story.php?storyId=5227744

Cheers,
Ed Gerck

Re: Comparison Of Secure Email Technologies X.509 / PKI, PGP, and IBE

2005-12-21T11:58:00.000-08:00

Andrew,

You make some good points. The purpose of the paper is to show
where and what the problems are -- and motivate solutions.

The points you note are not technology limitations of usability
but implementation problems. Also, in business use, clients can
be chosen among those that work and the proper infrastructure
provided. The usage difficulty ("I can't even use it") exists
mostly for open-ended Internet use. Of course, we still have all the
other difficulties pointed out in the paper

Regards,
Ed Gerck

--- Andrew Patrick wrote:
> Hi;
>
> I have not read your paper in detail, but thought I
> would mentioned problems that I have had in using
> X.509 based email signatures.
>
> It boils down to the fact that email messages signed
> with X.509 certificates break a number of message
> clients at the receiving end to the point that I have
> given up on signing my email.
>
> Some clients simply fail to display the signed
> messages (usually webmail systems).
>
> Other clients assume that a message received with a
> signature must be replied to in a signed fashion, and then
> break when the replier does not have a certificate
> configured (MS Outlook Express).
>
> Some mail clients alter the incoming message (i.e., to insert
> ads, ala Yahoo mail), so a message integrity check fails, and
> some usually cryptic error mesage is shown to the receiver.
>
> So, in my mind secure email systems suffer from the
> most sever usability problem -- they don't work.

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-17T09:05:00.000-08:00

James A. Donald wrote:

From: Werner Koch
You need to clarify the trust model. The OpenPGP
standard does not define any trust model at all. The
standard merely defines fatures useful to implement a
trust model.

"Clarifying the trust model" sounds suspiciously like
designers telling customers to conform to designer
procedures. This has not had much success in the past.

People using PGP in practice verify keys out of band,
not through web of trust.

James (and Travis, re previous posting on PGP trust model),

Yes. Your observation on out-of-band PGP key verification
is very important and actually exemplifies what Werner
wrote. Exactly because there's no trust model defined
a priori, uses can choose the model they want including
one-on-one trust.

This is important because it eliminates the need for a
common root of trust -- with a significant usability
improvement.

If the web of trust is used, the sender and recipient must
a priori trust each other's key signers, requiring a
common root of trust -- that may not even exist to begin
with.

So, instead of worrying about what trust model PGP uses,
the answer is that you can use any trust model you want --
including a hierarchical trust model as used with X.509.

Jon Callas and I had several conversations on trust in
May '97, when Jon visited me for two weeks while I was
in Brazil at the time, I think before the OpenPGP WG was
even working on these issues. This is one of the comments
Jon wrote in a listserv then, with a great insight that
might be useful today:

As I understand it, then, I've been thinking about some
of the wrong issues. For example, I have been wondering
about how exactly the trust model works, and what trust
model can possibly do all the things Dr Gerck is claiming.
I think my confusion comes from my asking the wrong
question. The real answer seems to be, 'what trust model
would you like?' There is a built in notion (the
'archetypical model' in the abstract class) of the meta-
rules that a trust model has to follow, but I might buy a
trust model from someone and add that, design my own, or
even augment one I bought. Thus, I can ask for a
fingerprint and check it against the FBI, Scotland Yard,
and Surite databases, check their PGP key to make sure
that it was signed my Mother Theresa, ask for a letter of
recommendation from either the Pope or the Dalai Lama
(except during Ramadan, when only approval by the Taliban
will do), and then reject them out of hand if I haven't had
my second cup of coffee.

Cheers,
Ed Gerck

Re: about secure email technologies

2005-12-15T20:26:00.000-08:00

--- Dino Esposito wrote:

> Mr. Gerck
> I skimmed through your "comparison of secure email
> techs..." and it
> seems to me that some of the desirable features and
> problems are outside
> the scope of the proposed technics (PKI, PGP, IBE).
> I mean, they are
> requirements about the mail protocols (e.g. return
> receipt) or SSL
> (Server spoofing).

The secure email technology may be able to directly
include a feature, in which case there's a check mark.
If the feature can't be included, an additional protocol
may be used to provide it. For example, server spoofing
could be prevented in IBE, directly, when the user
connects to the PKG to get the key (prventing credential
compromise for the real PKG).

> My field is PKI, and I think PKI
> (perhaps PGP too)
> can supply some basic technologies in order to build
> a "Secure email
> system", but it's unable to supply the full
> solution.

which must, most importantly, be usable. That's why
the paper can be useful to both improve PKI (what's
missing?) and to provide a view to new technologies
that can overcome current limitations.

> In Italy we have set up a quite complex legal and
> technical framework in
> order to have a "registered email" with all the
> features of the
> traditional registered mail and some plus (not only
> the sending is
> certified, but also the content and the integrity of
> the messages). This
> framework rules the single message AND the mail
> service providers, that
> have to be accreditated as the most trusted
> Certification Service Provider.
> These rules do not address confidentiality (SSL is
> mandatory, but the
> accreditated mail servers are nevertheless able to
> read any message),
> but this is probably the simplest issue since
> encrypting the body of a
> message is quite easy

But decryption is not, as the private-key must
be protected. That's where it's more difficult.

> I'm going to summarize these rules in English for
> other purposes; if you
> are interested I can send you as soon as available.

Yes, please do!

> Finally, I think that "F17 Verified Timestamp" is a
> feature supplied by
> PKI: the timestamp token as defined by the RFC3161

Yes, it is. It's now added in the table.

Ciao,
Ed Gerck

Re: Comparison of X.509 / PKI, PGP, and IBE

2005-12-15T20:22:00.000-08:00

- Michael Ströder wrote:

> Ed,
>
> you've asked for feedback on
> http://email-security.net/papers/pki-pgp-ibe.htm.
>
> "1. DESIRABLE FEATURES REFERENCE SHEET"
> I don't understand F18 and F19. Maybe you're
> referencing transparent
> encrypting of e-mail attachments? But then this
> should not be limited to
> HTML attachments.

Yes, you're right. It has been improved in the new
version at
http://email-security.net/papers/pki-pgp-ibe.htm

> Personally I'd never use a e-mail software which
> follows this requirement:
> "(**) [..] If the recipient wishes to decline to
> provide the receipt,
> the recipient should not attempt to decrypt the
> message."

This is the same rule that postal mail follows. The
receipt is useful for both sender and recipient, in
addition as evidence for the sender; for example, if
the sender knows that the recipient read (decrypted)
the email, the sender does not have to send another
email or make a call.

> "2. PROBLEMS / ATTACKS REFERENCE SHEET"
> P1 to P5 seems to be very much related to
> client-server processing. Are
> you pointing to web-based e-mail clients here? If
> yes, I'd suggest to
> make this more clear in the text by explicitly
> mentioning this type of
> service.

They apply to desktop-, intranet- or web- based. For
example P15 applies to PGP, web based or not.

> It's not clear to me why you list "F6 Base 64
> Encoding" as a feature.

It looks like a lame feature but some email products
do it better than others. For product evaluation you
can change the check mark to a product-specific grade.

Cheers,
Ed Gerck

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-13T23:51:00.000-08:00

Not to side track the discussion, but frequently I've heard PKI
compared to PGP's model.  Isn't PGP's trust model the same as everyone
being their own CA?

I find PGP to be problematic.  Many keys I see are only self-signed,
and this includes important keys like CERT.  Many others sit unsigned
on the same website you access to download the source code protected
by it.  And 90% of the time when they have more than one signature you
don't have a key that signed the other party's key, so you get to do a
breadth-first search manual-like (pathserver being dead and all).
Even with kgpg pulling the keys from a keyserver for you, it's still
non-trivial.

I successfully inspired a local keysigning, but it seems like most of
the people didn't see any immediate benefit, and so declined to
participate.  "What does this mean for me" was a common question.  I
tried to explain the purpose, but I suspect it is too recondite or too
far removed from their experience.  Perhaps I'd have better luck by
stating what kind of attacks it would prevent (email spoofing being
relatively rare, save for some obvious spam tactics).  I'm open to any
suggestions along these lines.

--
Travis H.

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12T10:11:00.000-08:00

James A. Donald wrote:

> This was the scenario envisaged when PKI was created,
> but I don't see it happening, and in fact attempting to
> do so using existing user interfaces is painful.  They
> don't seem designed to do this.
> 
> My product, Crypto Kong, http://echeque.com/Kong was
> designed to directly support this scenario in a more
> convenient fashion - it keeps a database of past
> communications and their associated keys, but there did
> not seem to be a lot of interest.   I could have made it
> more useful, given it more capabilities, but I felt I
> was missing the point


i've seen some discussions that were either/or regarding pki & pgp;
aka pki advocates attempting to position pki as a OR to pgp. the issue
is that both pki and pgp require a local trusted public key repository
as the basis for establishing trust.

pki then layers on it, these certification authority business processes,
specialized digitally signed messages called digital certificates, etc
to address first time communication between strangers where the relying
parties have no other resources for determining information about the
sender in an offline environment. they then advocate that all
(personally) digitally signed operations are required to have attached
x.509 identity digital certificates that has been digitally signed by a
certification authority.

we saw some of that when we did work on the cal. state & fed. electronic
signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

one possible interpretation might be that it would have increased the
revenue stream for the certification authority industry.

drastically improving the useability of the interface to the trusted
public key repositories could be viewed as having two downsides 1)
certification authorities that haven't payed to have their public keys
preloaded can more easily join the club, 2) the pgp-like scenario
becames much easier, potentially drastically reducing existing reliance
on the digital-certificate-only (and certification authority only
business process) digital-signed-operation model.

part of the problem with the trusted third party certification authority
model is that its primary benefit in the case of first time
communication betweeen two strangers ... where the relying party has no
other recourse to information about the other party. this is actually an
extremely small percentage of communications. we saw some of this
working on the original e-commerce activity
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

where we layed out hypothetical certification issues for merchants ...
including things like having FBI background checks for all merchant
employees. the problem is that e-commerce transactions have been quite
bi-model whith the largest percentage of transaction occuring as repeat
business with well-known merchants. in these cases, consumers have
established trust via a large number of other mechanisms ... so there is
little added value that a certification authority can provide ...
especially if they aren't willing to stand-behind and guarantee all
merchant transactions (ssl then is primarily countermeasure to
mitm-attack and evesdropping on transaction as opposed to a
certification/trust issue).

the rest of the remaining transaction are spread around to a large
number of different merchants having a few transactions each. the issue
here is that the incremental revenue flow for a few transactions a month
couldn't possibly cover the cost of a certification process that
involved things like fbi background checks on all merchant employees.

the large majority of transactions are either repeat business and/or
with extremely well-known merchants ... this doesn't satisfy the PKI
target profile of first time communication between complete strangers.
simple countermeasure to mitm-attack and countermeasure is achieved by
having stored the merchant's public key (from the consumer's standpoint).

from the merchant standpoint they already have transaction guarantees on
credit card processing from their contract with financial institution.
the threat/vulnerability model here is client-originated fraudulent
transactions that aren't strongly authenticated. here, x9.59 standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

allows for digitally signed transaction where the public key is
registered with the consumer's financial institution and the digital
signature is verified by the consumer's financial institution as part of
verifying the transaction.

the other part of x9.59 standard is that it specifies that account
numbers used in x9.59 transactions can't be used in non-authenticated
transactions. this eliminates both data breaches and evesdropping as a
threat/vulnerability for fraudulent financial transactions ... aka the
requirement given the x9a10 working group for x9.59 standard was to
preserve the integrity of the financial infrastructure for all retail
payments. if data breaches and evedsdropping no longer can result in
fraudulent transactions, then there is much less reason for
sophisticated countermeasures for those threat/vulnerabilities (ssl is
no longer needed to prevent evesdropping on the account number, since
evesdropping on the account number no longer provides any practical
fraudulent benefit).

simple public key registration as part of financial account operation
(in an onging relationship that a consumer has with their financial
institution) not only is a certificateless digital signature model
http://www.garlic.com/~lynn/subpubkey.html#certless

but also eliminates much of the requirement for existing major use of
digital certificates; that of providing ssl encrypted communication
http://www.garlic.com/~lynn/subpubkey.html#sslcert

as countermeasure for evesdropping for the purpose of account number
havesting
http://www.garlic.com/~lynn/subpubkey.html#harvest

furthermore, not only does simple x9.59 digital signature authenticated
transactions eliminate the threat/vulnerability of evesdropping for
account number harvesting, but it also eliminates the
threat/vulnerability of data breaches for account number harvesting
aka the harvesting could still go on, but the threat/vulnerability of
fraudulent transactions as a consequence of harvesting is eliminated ...
note that phishing attacks for the purpose of account number harvesting
is also eliminated as a threat/vulnerability ... phishing can still go
on, account numbers cna still be harvested, the account numbers are
useable for fraudulent transactions w/o the digital signature.

misc. past posts mentioned bi-model transaction distribution and/or
having suggested employee fbi background checks as part of merchant
certification process.
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean
Anything?

Anne & Lynn Wheeler

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12T10:08:00.000-08:00

James A. Donald wrote:

> > However, the main point of attack is phishing, when
> > an outsider attempts to interpose himself, the man
> > in the middle, into an existing relationship between
> > two people that know and trust each other.

Anne & Lynn Wheeler wrote:

> in the traditional, ongoing relationship scenario,
> relying parties directly record authentication
> information of the parties they are dealing with. if a
> relying party were to directly record the public key
> of the people they are communicating with ... it is
> the trusting of that public key and the validating of
> associated public key operations that provide for the
> countermeasure for man-in-the-middle attacks and
> phishing attacks.


This was the scenario envisaged when PKI was created,
but I don't see it happening, and in fact attempting to
do so using existing user interfaces is painful.  They
don't seem designed to do this.

My product, Crypto Kong, http://echeque.com/Kong was
designed to directly support this scenario in a more
convenient fashion - it keeps a database of past
communications and their associated keys, but there did
not seem to be a lot of interest.   I could have made it
more useful, given it more capabilities, but I felt I
was missing the point

        James A. Donald

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12T10:04:00.000-08:00

On Fri, 9 Dec 2005, Ed Gerck wrote:

> [...]                                          at least the grand
> picture should exist beforehand. This is what this thread's subject
> paper is about, the grand picture for secure email and why aren't
> we there yet (Phil's PGP is almost 15 years old) -- what's missing.
>


and Bill Stewart wrote:

> Popularity of a product is critical to its security;
> you don't gain anonymity if the Feds can recognize that
> you're one of the dozen users of a given application.
> Your mom can use Skype, but nobody she knows uses Crypto Kong,
> and I only know a few people who use PGP to email their mom.
> But some of the Instant Messaging systems use crypto;
> too bad that they're continually trying to be incompatible
> with each other to gain market share.


I think what's missing is the understanding that there cannot be
secure email without the persons involved acting responsible and
knowing their role in the process.

Your mother will probably expect the computer to do the job for her
(mine will never expect anything from computers) rejecting any
responsibility for her email's security. In my opinion establishing
secure email this way is impossible despite the fact that encryption is
(relatively) easy if our algorithms work as expected and you have the
correct high-quality public key.

And even if Instant Messaging systems would use the same crypto people
will use them like cell phones without any consciousness of their own
responsibility for key validation. Getting good crypto into mass products
can help but does not eliminate the necessity for checking essential
properties of the system they use.

How we can make this job as reliable as possible is the question at the
heart of the problem.

Ralf Senderek

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-09T16:16:00.000-08:00

Simon McMahon wrote:

Nice paper! I especially liked the cited 'Johnny' paper.

Thanks!

What about denial of service attacks where super large RSA keys are
used or faked which either crash or tie up the server with decryption
and verification of bogus messages. Even a flood of normal
encrypted/signed messages have to be decrypted before the signature can
be checked. I've seen some messaging systems where the client encrypts
first, then signs (opposite of smime) to avoid decrypting invalid
messages on the server.

You make a good point -- if encryption is made simpler and more people
use it, it will be attacked. Reader "dgustafson1" (see blog at
http://email-security.blogspot.com/2005/12/re-x509-pki-pgp-and-ibe-se_113408257591787133.html)
also comments on not to be forced to spend time handling mass quantities
of unwanted secure messages (e.g., encrypted spam). Providing an
additional signature to be verified before decryption could help,
as you point out for S/MIME.

The paper does take this problem into account, but it does so in a
technologically-neutral way, using F10 (Meets Digital Signature
Requirement), F11 (Authenticates Sender and Recipient) and absence of
several P#'s especially P6 (Unverified Sender's Email Address). Please
check the blog (entry above) for my comments on this.

P6 is important here because if you can trace the sender (there's no
spoofed sender email address), not only the sender becomes liable
but you have now a fixed, verified target to accept or block beforehand.

I used to work with HSMs (hardware crypto & key storage) and we used to
get many requests for accelerated crypto and strong key storage.
Standard interfaces to crypto subsystem was the feature we required.
Some corporate users can justify the cost of this feature.

But even with HSM, root operators can do a lot to undermine user security,
including reading email. Banks routinely separate development from
operation, even with HSM, so that operation personnel do not become aware
of vulnerabilities. Another example is the "no loner" policy for handling
sensitive data, even with HSM.

Not only conflicting business interests are of concern here but also
unnoticed data mining, blackmail, disclosing trade secrets and many other
activities (even legal) that break user's privacy, HSM or not, to benefit
someone. The market knows this, as we could see in the rejection of MS
Passport, proposing to hold data of other businesses' users in secure
storage at Microsoft.

That's why the lists of features and problems / attacks in the paper have
several items to protect user's privacy. What's the point of email
encryption if the supposed secure channel is actually open (even if just
to one eavesdropper)? It may be even worse than no encryption at all,
because there'd be a presumption of confidentiality by the communicating
parties.

Key-escrow (encryption key only) allows content filtering and law
enforcement agencies to function. Sounds like IBE has that capability.

IBE has that capability by construction. Some papers suggest that the
effects can be constrained if the IBE reduces each key's usage to a few
or even to one message. However, even if the security parameters for the
IBE change for every user's key (which would be a huge burden for all
recipients and senders) a simple data logging device at the Private
Key Server (and/or at the recipient's end) could log all keys and allow
any message to be read.

Of course, a country's laws may require key escrow or key discovery.
And businesses, to prevent problems if the proverbial bus hits an
employee, may also require key escrow (and that's why a biometrical
access system requires a backdoor, which is yet another problem).
However, providing key escrow without a choice, for everyone, might
create more problems, for example if the watchers become targets
themselves.

The key escrow debate was very active in the 90's. More problems than
benefits. Law enforcement can break and use communication information
(ie, routing, IP numbers, time, frequency of use, etc.) much more
easily than message information, and use it more effectively too. People
can always use a simple one-time code book or jargon to defeat any key
escrow scheme. The secret channel created by the code-talkers in WWII
was, reportedly, never broken.

Also, these email systems are only discretionary - the user has to
choose to send / receive securely. None of them (afaik) support
mandatory security where the security is always on and cant be
disabled or ignored by the user.

Some do, by enforcing a security policy -- e.g., "email to boss@home.com
must be sent encrypted". Receiving securely can also be defined by the
sender; if I sent it encrypted, you have no choice.

At least with some clients they can be set to
default to secure which is a bit better. I guess that is a feature of
the email client regardless of the crypto technology though.

Yes, and that's why I did not include it in the paper.

Thanks for the good comments!

Ed Gerck

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T17:16:00.000-08:00

Anne & Lynn Wheeler wrote:

i've periodically written on security proportional to risk ... small sample
http://www.garlic.com/~lynn/2001h.html#61

...
introductioin of PKI and certificates in such an environment may
actually create greater vulnerabilities ... since it may convince the
recipient to trust the PKI operation more than they trust their own,
direct knowledge ... and the PKI operation opens up more avenues of
compromise for the attackers.

Regarding PKI, the X.509 idea is not just to automate the process of
reliance but to do so without introducing vulnerabilities in the threat
model considered in the CPS. Further, X.509 simplifies what it provides
to the least possible _to_automate_ and puts all the local and human-based
security decisions in the CPS.

For example, let's see an oft repeated issue of "a crook attacking the
authoritative agency that a certification authority uses for the basis
of its certification, and then getting a perfectly valid certificate".

This is not really about X.509 or PKI, it's about the CPS. If the CPS
says it restricts cert reliance to the assertion that the subscriber's
email address was timely responsive to a random challenge when the cert
was issued, then relying on anything else (e.g., that the email address
is owned or operated by an honest person, or by a person who bears a name
similar to that mailbox's username, or even by a person at all) is
unwarranted. With this CPS, there was really no "attack" on the CA and the
cert _is_ perfectly valid -- all it does is authenticate the email address
that _was_ verified.

What's a bit of a struggle, thus, is that many subscribers and relying-
parties do not fully realize that the CPS is outside the scope of PKI and
yet defines the email security model for that PKI -- what you can trust
and what you can't. Yes, in this regard, there are as many PKIs as there
are CAs and this is reflected in the paper as problem P16 (Requires Common
Root Of Trust).

Having the CPS outside the scope of X.509/PKI is both a solution (makes
the X.509 effort independent of local needs) and a big problem, as CAs
(writers of the CPS) have the power to write almost anything they want,
including their notorious DISCLAIMER (where _near_ everything of value to
the subscriber is disclaimed, while _everything_ of value to the relying-
party is disclaimed).

That's why its useful to compare X.509 / PKI, PGP, and IBE technologies
for secure email, to know what are the trade-offs.

By comparing the capabilities and faults of the secure email products
per technology used, these and other problems come up in the score card.

Cheers,
Ed Gerck

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T14:54:00.000-08:00

dgustafson1 wrote:
>
> Hi Ed,
>
> Things that are interesting that may not be in your charts:

Thanks for the good points. My comments are inlined.

> Fx = Secure Message Exchange Negotiation
> ----------------------------------------
> Ideally, if a correspondent's email address is known, it should be easy
> to start the exchange of secure messages with that correspondent. It
> should be possible to query the entity's email address for any
> information necessary to initiate exchange of secure message(s). Intent
> is to _not_ require a single, world-readable directory of all potential
> email correspondents and their current email address(es), etc. -- the
> existence of which would likely have disastrous consequences.

The lack of this feature is what problems P13 (Must Pre-Enroll Recipients)
and P16 (Must Send Own Certificate) are about. I preferred to list the problems
rather than the feature because it explains the two parts of the issue, is more
concise and is technologically-neutral. Describing the feature (as above) would
require a longer text, and talking about a directory (for example).

In other words, if the secure email system does NOT have problems P13 and P16,
there is no need to talk about Fx.

> F(x+1) = Secure Message Exchange Recipient Privacy
> --------------------------------------------------
> Conversely, it should be possible for each correspondent to exert their
> personally desired level of control over just who is able to access to
> his/her email address and, particularly, the corresponding security
> profile. Perhaps analagous to Caller-ID, the individual user
> (recipient) can determine which queries receive valid security
> information and which are handled in some other way. Intent is to allow
> desired message exchange but not be forced to spend time handling (mass
> quantities of) unwanted secure messages.

If there is no need to grant access to "valid security information" to the
sender (because P13 and P16 do not exist), then F(x+1) is not needed to protect
the recipient's privacy.

However, you still make another good point: the recipient should not be
forced to spend time handling (mass quantities of) unwanted secure messages.
Which may be even worse if anyone can easily send you a secure message
(because P13 does not exist).

This problem (i.e, allowing the recipient to determine which secure
message to decrypt) is handled by a combination of F8 (Identity
Certificate) viewed before decryption, F10 (Meets Digital Signature Requirement)
to make sure the message is not spoofed even though it is signed, F11 (Authenticates
Sender and Recipient) to make sure the sender is not spoofing a valid credential,
with absence of several P#'s especially P6 (Unverified Sender's Email Address).

P6 is important here because if you can trace the sender (there's no spoofed
sender email address), not only the sender becomes liable but you have now
a fixed, verified target to accept or block.

> F(x+2) = Secure Message Exchange Blocking
> -----------------------------------------
> Ability to "undo" an earlier decision to engage in secure message
> exchange with a particular correspondent or group of correspondents. I
> want to "revoke" my credential specifically with respect to future use
> for communication with certain other correspondent(s).

F(x+2) is not needed for the reasons above -- those correspondents do not
need to access security information from you and you can easily block them.

> Obvously, I don't have a specific solution in mind and have not tried to
> separate these capabilities cleanly. They'll all kind of run together
> at first. Also, I don't care whether public key, secret key, DH key
> exchange, x.509 certificates, or (any other crypto technology) is used
> in any solution.

Yes, that's why the paper uses features and attacks/problems that are
technologically neutral and uses them to create a technologically-neutral
score card, that is also product-agnostic.

> The main point, at the outset, is to define a compellingly service that
> has sufficient benefits to drive the efforts necessary to achieve it's
> development (i.e., as opposed to allocating resources on other
> activities). All of us have been waiting for at least 10 years to start
> using secure email (i.e., as we know it today). A decade of collective
> experience strongly suggests there must be some new thinking before
> things will be able to move ahead.

Yes. The work provides a view to both improve the email security technologies
X.509 / PKI, PGP and IBE, and develop the specifications for new technology
beyond current limitations.

Cheers,
Ed Gerck

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T12:17:00.000-08:00

Lars Eilebrecht wrote:

According to Ed:

To help develop a common yardstick, I would like feedback (also by
private email) on a list of desirable secure email features as well
as a list of attacks or problems, with a corresponding score card for
the secure email technologies X.509 / PKI, PGP and IBE. The paper
is at http://email-security.net/papers/pki-pgp-ibe.htm

Nice paper. I don't had time to look at it in detail, but here a
few minor comments ...

Lars,

Thanks for your nice words.

I think it would be better to have different tables for
attacks vs. problems. For example "must pre-enroll rcpts" may
be an "unwanted feature", but it really something different
compared to an attack, i.e., a problem leading to an attacks
such as "open message headers".

In order to make some progress on this, I felt a need to
simplify things into + and -. This makes sense also in
terms of attacks vs problems because a system that has
a lot of problems will likely be used badly (insecurely)
or not at all -- which opens room for attacks. So, both
problems and attacks are negative for security.

[See also my previous reply on this to the posting by James Donald,
in this blog]

Further, I'm not sure about the general categories you have.
"PKI" is a very broad term. PGP and it's web-of-trust is
also some kind of PKI and of course I could build a closed/private
PKI using OpenPGP keys.

That's why I had "X.509 / PKI" -- even though PGP's
WOT doesn't qualify as a PKI (no central management).
They are also fundamentally different in other aspects.
I've summarized this in http://nma.com/papers/certover.pdf

It may be easier to compare the different technologies if
you compare the message format (e.g., S/MIME vs. PGP/MIME)
independent from the rest of the system, i.e., from the PKI.

The different technologies are compared in terms of the
market products they support. It's a capability (and lack of
capability) analysis.

The message format (and the application) reflect what
the technology needs and can provide support for. S/MIME
is not the same as PGP/MIME, in the same way that the old
PEM was also different (and there's also PGP without PGP/MIME).

As "PKI technologies" I would think of X.509-based PKIs (PKIX),
vs. IBE-based vs. OpenPGP-based ...
An attack against "open message headers" is not related to
a system using X.509 certs or OpenPGP keys, but it just
a matter of the message format being used, e.g., S/MIME.

I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.

[See also my previous reply on this to the posting by James Donald,
in this blog]

If I remember correctly most IBE-based system also use
S/MIME or at least something derived from it like the Voltage
IBE product.

This is not so relevant for the analysis.

For example, both X.509 and IBE (suppose) support S/MIME.
However, that doesn't make them equal in terms of their
features (the + in the score cards). You can revoke a X.509 key
and have S/MIME tell you that for X.509 (score a + there)
while you can't revoke an IBE key (doesn't score the +).
However, you could expire both X.509 and IBE keys (even
though Voltage does not say it for their product, it's in
their IBE papers) and, therefore, both score a + there.

And an attack related to how key revocation is handled is
unrelated to a system using S/MIME or PGP/MIME.

Key revocation is expressed in S/MIME differently than in
PGP/MIME, though. In general, a technology's limitation
(for example, no central key revocation in PGP) will
reflect itself in the encoding used and in the product,
which is what is measured to create the score card.

BTW, have you considered adding the Ciphire system to your
comparison (http://www.ciphire.com)?

If you're familiar with that product, I'd like to add their
scores to the respective technology column.

Regards,
Ed Gerck

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T12:04:00.000-08:00

Nice paper! I especially liked the cited 'Johnny' paper.

What about denial of service attacks where super large RSA keys are
used or faked which either crash or tie up the server with decryption
and verification of bogus messages. Even a flood of normal
encrypted/signed messages have to be decrypted before the signature can
be checked. I've seen some messaging systems where the client encrypts
first, then signs (opposite of smime) to avoid decrypting invalid
messages on the server.

I used to work with HSMs (hardware crypto & key storage) and we used to
get many requests for accelerated crypto and strong key storage.
Standard interfaces to crypto subsystem was the feature we required.
Some corporate users can justify the cost of this feature. The problem
is inside attacks on software only cryptostores, the feature is
standardization which means crypto engine options are available.

Key-escrow (encryption key only) allows content filtering and law
enforcement agencies to function. Sounds like IBE has that capability.

Also, these email systems are only discretionary - the user has to
choose to send / receive securely. None of them (afaik) support
mandatory security where the security is always on and cant be disabled
or ignored by the user. At least with some clients they can be set to
default to secure which is a bit better. I guess that is a feature of
the email client regardless of the crypto technology though.

Regards,
Simon McMahon

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T12:03:00.000-08:00

Hi Ed,

Things that are interesting that may not be in your charts:

Fx = Secure Message Exchange Negotiation
----------------------------------------
Ideally, if a correspondent's email address is known, it should be easy to start the exchange of secure messages with that correspondent. It should be possible to query the entity's email address for any information necessary to initiate exchange of secure message(s). Intent is to not require a single, world-readable directory of all potential email correspondents and their current email address(es), etc. -- the existence of which would likely have disastrous consequences.

F(x+1) = Secure Message Exchange Recipient Privacy
--------------------------------------------------
Conversely, it should be possible for each correspondent to exert their personally desired level of control over just who is able to access to his/her email address and, particularly, the corresponding security profile. Perhaps analagous to Caller-ID, the individual user (recipient) can determine which queries receive valid security information and which are handled in some other way. Intent is to allow desired message exchange but not be forced to spend time handling (mass quantities of) unwanted secure messages.

F(x+2) = Secure Message Exchange Blocking
-----------------------------------------
Ability to "undo" an earlier decision to engage in secure message exchange with a particular correspondent or group of correspondents. I want to "revoke" my credential specifically with respect to future use for communication with certain other correspondent(s).

Obvously, I don't have a specific solution in mind and have not tried to separate these capabilities cleanly. They'll all kind of run together at first. Also, I don't care whether public key, secret key, DH key exchange, x.509 certificates, or (any other crypto technology) is used in any solution.

The main point, at the outset, is to define a compellingly service that has sufficient benefits to drive the efforts necessary to achieve it's development (i.e., as opposed to allocating resources on other activities). All of us have been waiting for at least 10 years to start using secure email (i.e., as we know it today). A decade of collective experience strongly suggests there must be some new thinking before things will be able to move ahead.

Good Luck & Best Regards,
--dg

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T12:02:00.000-08:00

On Wed, Dec 07, 2005 at 09:42:03AM -0500, Ed Gerck wrote:

> 
> 
> To help develop a common yardstick, I would like feedback (also by
> private email) on a list of desirable secure email features as well
> as a list of attacks or problems, with a corresponding score card for
> the secure email technologies X.509 / PKI, PGP and IBE. The paper
> is at http://email-security.net/papers/pki-pgp-ibe.htm


What's missing, except implicitly, is the most important feature of
all.  Ease of use and deployment.   What do users have to _do_ to get
the software, to get and maintain certificates (if required), and to
send and receive mail.


This is the most important feature because inattention to it has
caused both secure and insecure systems to not get used except by
a small minority of the population.   That the system be easy enough
to use that people will actually use it turns out to be as important
as how secure the system is against various threat models.   More
important than security against certain more rare threat models.

It's amazing how easy it is to get this wrong.  Did you know that
Microsoft Outlook, the most common email program in the world, has
opportunistic e-mail encryption if you
  a) Get a certificate (free from thawte)
  b) Click two checkboxes

Nobody uses it because of one very simple but giant mistake.  If
you turn on the checkboxes, then every time you send mail and
every time you receive encrypted mail, you get a dialog box popping
up asking to confirm if the program can access your private key.


(Also, nobody knows about it, and it uses giant ugly x.509/s-mime)


And one final note -- it is controversial to describe "return receipt"
as a feature.  For recipients, that's an anti-feature.

--
Brad Templeton

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T12:00:00.000-08:00

According to Ed:

> To help develop a common yardstick, I would like feedback (also by
> private email) on a list of desirable secure email features as well
> as a list of attacks or problems, with a corresponding score card for
> the secure email technologies X.509 / PKI, PGP and IBE. The paper
> is at http://email-security.net/papers/pki-pgp-ibe.htm


Nice paper. I don't had time to look at it in detail, but here a
few minor comments ...

I think it would be better to have different tables for
attacks vs. problems. For example "must pre-enroll rcpts" may
be an "unwanted feature", but it really something different
compared to an attack, i.e., a problem leading to an attacks
such as "open message headers".

Further, I'm not sure about the general categories you have.
"PKI" is a very broad term. PGP and it's web-of-trust is
also some kind of PKI and of course I could build a closed/private
PKI using OpenPGP keys.

It may be easier to compare the different technologies if
you compare the message format (e.g., S/MIME vs. PGP/MIME)
independent from the rest of the system, i.e., from the PKI.
As "PKI technologies" I would think of X.509-based PKIs (PKIX),
vs. IBE-based vs. OpenPGP-based ...
An attack against "open message headers" is not related to
a system using X.509 certs or OpenPGP keys, but it just
a matter of the message format being used, e.g., S/MIME.
If I remember correctly most IBE-based system also use
S/MIME or at least something derived from it like the Voltage
IBE product.
And an attack related to how key revocation is handled is
unrelated to a system using S/MIME or PGP/MIME.

BTW, have you considered adding the Ciphire system to your
comparison (http://www.ciphire.com)?


ciao...
--
Lars Eilebrecht

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T11:57:00.000-08:00

"James A. Donald" writes:

> ...  email should be sent by a direct connection from the client to
> the recipient mail server, rather than this store and forward crap.


This would eliminate the only available technique for strong anonymity
or pseudonymity.  Strong anonymity or pseudonymity cannot be achieved
if there is a direct connection from the sender to the recipient
because it can be traced.  For strong anonymity or pseudonymity, the
only available secure technology is anonymizing remailers with random
latency store and forward.

StealthMonger

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T11:12:00.000-08:00

James A. Donald wrote:

http://email-security.net/papers/pki-pgp-ibe.htm

X.509 / PKI (Public-Key Infrastructure), PGP (Pretty Good Privacy) and IBE (Identity-Based Encryption) promise privacy and security for email. But comparing these systems has been like comparing apples with speedboats and wingbats. A speedboat is a bad apple, and so on.

We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm,

Boats are storm rated, however. The point here is how can we
"storm rate" secure email systems?

For example, it might be a good idea to have different tables for
attacks vs. problems (for boats: resisting pirates versus
resisting high waves). For example P13 (must pre-enroll recipients) may
be a problem and it really is something different compared to an
attack, i.e., a problem leading to an attack such as P12 (open message
headers).

However, in order to make some progress in this, I felt a need to
simplify things into + and -. This makes sense also in terms of
attacks vs problems (for email, maybe not for boats!) because a
secure email system that has a lot of problems will likely be used
badly (insecurely) or not at all -- which opens room for attacks.
So, both problems and attacks are negative for security.

What I'm saying is that we can, and do in many other cases,
compare different systems in terms of their features and
shortcomings. Irrespectively of how we may further classify them,
a feature is + and a shortcoming is -. For example, that's how your
car value is estimated when you sell it -- by how many negative and
positive points it gets. It doesn't matter if the negative points
came from a dent or an absence of air bags, they all count negatively.
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
To do this, the paper asks two questions:

(1) what are the product's capabilities in terms of a list of desired
features (the +), and

(2) what are the product's shortcomings in terms of a list of attack/
problems (the -),

for each main market product using those technologies and assigns each
score (+ or -) to the technology used by that product. At the end
of this algorithm, scanning enough products, we have a list of all
capabilities and all shortcomings that affect each technology.

Of course, each feature and problem/attack is intended as optional --
you can pick and choose what you want from the list, to make your
own subset of the score card, valid for your needs (and amount of
money you want to pay).

These lists are an intrinsic "yardstick" that we can use to both rate each
technology and also, if we want, each individual product. For example, a
product that has 80% of the positive score and 20% of the negative score
for that technology is possibly better than a product using the same
technology that would have 20% of the positive and 80% of the negative
for that technology. We can, in the same way, compare products using
different technologies, comparing their score cards.

Problem 1: The primary weakness of existent email is its vulnerability to after the fact investigations.

For example P1: giving others the ability to get your private
key at a server without your knowledge or consent.

Anything we can do to negate "after the fact investigations" is
useful , such as protecting the email headers (communication
security, not just message security). The paper's score card
reflects several aspects of this, in its positive and
negative scores.

Problem 2: The secondary weakness is ease of forgery.

For example P1 to P8.

Crap with certificate authorities or web of trust just is not flying, and is not going to fly.

Depends on your use. An X.509 identity cert or a PGP cert
can be made as secure as you wish to pay for. The real
question, however, that is addressed by the paper is
how useful are they in terms of email security? How do
you compare them and which one or which product to choose
from? What are the trade-offs?

To limit the number of
possible copies, email should be sent by a direct
connection from the client to the recipient mail server,
rather than this store and forward crap.

Store and forward makes it reliable -- nothing needs to be
100% online 100% of the time (a totally improbable event).

Cheers,
Ed Gerck

X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08T11:10:00.000-08:00

http://email-security.net/papers/pki-pgp-ibe.htm

X.509 / PKI (Public-Key Infrastructure), PGP (Pretty Good Privacy)
and IBE (Identity-Based Encryption) promise privacy and security
for email. But comparing these systems has been like comparing apples
with speedboats and wingbats. A speedboat is a bad apple, and so on.

To help develop a common yardstick, I would like feedback (also by
private email) on a list of desirable secure email features as well
as a list of attacks or problems, with a corresponding score card for
the secure email technologies X.509 / PKI, PGP and IBE. The paper
is at http://email-security.net/papers/pki-pgp-ibe.htm

The list of desirable secure email features and the list of attacks /
problems might also be useful in terms of improving secure email
support.

Cheers,
Ed Gerck

Re: [IP] announcing email-security.net

2005-10-07T11:23:00.000-07:00

on Friday, Oct 07, 2005 Steven Champeon wrote:

> Ed Gerck wrote:

> But don't we have two different actors here? Encryption has to do
> with the end-user while the other points you mentioned have to do
> with sysadmins. For the user, those other points you mention not only
> have zero priority but they can't do a thing about them, even if they
> would want to.


OK, point granted. I guess all I am saying is that if I had to choose
one thing to fix, getting the world's mail servers to support RFC 2821
would take priority over getting the world's end users to encrypt all
their mail.

> My discussion paper asks why users don't encrypt. Sysadmins are not
> a significant part of the answer, I think.


Agreed. The lack of a common PKI, I think, is the major factor here.
Email (unencrypted) doesn't require a handshake and key exchange (or
at least, not one visible to and requiring action on the part of,
the end user - this transparency is made possible, of course, by the
sysadmins whose role you minimize).

> OTOH, encryption and signatures can make it a lot easier to reject
> spam and prevent email fraud, which backfire to sysadmins.


But that's a zero sum game. Either everyone encrypts, or you don't gain.

> >Nowadays it seems the marketing folks are running the show and have lost
> >touch with what a basic user needs. It's a terrible state of affairs.

> 
> That's a problem and David Farber had problems with this too. But first note
> that PGP and Outlook are on opposing camps. Outlook works fine with
> RSA-S/MIME and MSFT has no interest in support anything PGP related.
> PGP folks don't like MSFT either.  Also, as I will comment in Part II,
> there's a fundamental problem why PGP and S/MIME are not very useful
> for email encryption. The marketing folks, either way, face a losing
> battle. It's not even a matter of a better user interface, even if
> very clever.


I'm looking forward to part II.

Re: [IP] announcing email-security.net

2005-10-03T11:55:00.000-07:00

on Sun, Oct 02, 2005 at 12:53:40PM -0700, Ed Gerck wrote:

> Steven,
> 
> Thanks for your interesting message, to help
> stir the pot. I published it in the site's
> blog and RSS, at http://email-security.net
> 
> BTW, did you read the paper in the site?


Yes. Don't get me wrong - I do think encryption is important, I just think it's a lot lower priority than those others I mentioned.

> About Outlook, it comes with S/MIME encryption at
> no cost.PGP is also available free and. PGP is
> also free for personal use at hushmail as a web
> service.


We have several clients who use PGP (or GPG, in some cases) to protect email from Web forms, etc. Every time we've had to go in and try to find, download, and/or purchase the official "basic" PGP plugin package from pgp.com, we've been baffled by the whole product line. It used to be you could just get a plugin (for Eudora, I'm sure, and probably also for Outlook, but I don't recall) that would allow you to
sign/encrypt/decrypt/verify messages, manage keys, and that was it.

Nowadays it seems the marketing folks are running the show and have lost touch with what a basic user needs. It's a terrible state of affairs.

--
Steven Champeon

RE: [IP] announcing email-security.net

2005-10-02T12:42:00.000-07:00

It seems to me that encryption is the least of our problems, as complex, confusing, costly (tried to download a free PGP plugin for Outlook lately?) and as generally unnecessary as it is (for the vast majority of messages, anyway).

This is especially true and unsurprising when you realize that many mail servers out there:

- don't identify themselves (using HELO or EHLO) using strings that remotely resemble valid Internet host/domain names, as required in RFC 2821, section 4.1 ff. I've seen unbracketed IPs, RFC 1918 IPs, "localhost", "localhost.localdomain", ".", and my all-time fave:

schampeo@habanero:1029 $ host 209.0.51.16 16.51.0.209.in-addr.arpa domain name pointer Alameda.net.has.not.owned.this.ip.for.more.then.four.years.

- as such, don't reject much mail based on forged/bogus HELO, because hey! nobody does it properly, so it's not a valid grounds for refusing spam and viruses. This even though late 2003 saw massive attacks from worms and viruses that HELO'd with the NetBIOS name of the infected computer! Later versions learned that some folks blocked HELOs with no "." and so started appending a random ".com", ".net" or ".org" to the NetBIOS name of the infected computer. :/ I believe now that some append a legitimate domain name (so you get "oemcomputer.erols.com" instead of just "oemcomputer"). No matter that the names don't exist.

- don't refuse mail, even when the sending "client" claims to be the IP or any of the hostnames known to the server (in other words, they walk up and say "Hi, I'm Dave Farber! Want some cheap meds?")

- accept unwanted messages, and then, after missing the chance to refuse inline, trust the almost always forged or bogus sender when generating NDN messages (known as "outscatter", a clarification of the older term, "backscatter", which was misleading), resulting in a flood of third party abuse and still more vectors for infection or promulgation of the spam.

- don't have matching forward and reverse DNS (or don't have rDNS at all, despite AOL's refusal to accept mail from such hosts)

- don't have reverse DNS that indicates that the server handles mail (or have rDNS that suggests that it's just part of a pool of dynamic addresses, or about which even less is known) so hapless mail admins can tell the difference between, say,

ip-65-38-111-161.hou.vericenter.com

and the tens of thousands of other infected hosts that start with

ip-1-2-3-4

in over a hundred domains (I know about at least 124 domains using that naming convention) that are actively spamming us. The example given is an edge case, as it has two PTRs, one given above, the other is mail.schipul.net. Unfortunately, it HELOs as something else entirely. :/

-don't support SMTP AUTH or port 587 for submissions, because it's ridiculously complex to try to provide tech support for people using Outlook or other mail clients that don't support SMTP AUTH in a useful manner, or make enabling it such a battle that you may as well write a new client to save time.

- don't support TLS because they have to pay exorbitant fees to monopolists in order to use encryption

- don't block viruses inline, even though it's fairly obvious from simple header inspection which files are likely to be infected (or, more importantly, which files are likely to be able to exploit bugs in mail clients, due to the 3-character extension mapping) and instead accept likely infected mail, scan it, and sometimes even send a copy back to the (forged) "sender", spreading the virus further. Road Runner recently started /cleansing/ such messages and then sending an annoybot message to the (forged) "sender", even though nearly all modern mass mailing viruses are known to forge senders.

- don't include adequate audit trail for injected messages, such that they can be traced to the IP of origin (hotmail often inserts an IP in hotmail.com network space, due to a faulty NAT setup; gmail uses RFC 1918 10/8 addresses; cnchost/concentric, erasmas.com, clara.net, powweb.com, btconnect.com, cp.net, web.de, inet.it, infovia.com.ar, atlas.cz, spray.net, arcor-online.net, tiscali.fr, centrum.cz, bluewin.ch, optusnet.com.au, excite.it, tiscali.com, go.com, et al. all have lousy audit trails).

- don't wait for the remote server to issue a 220 greeting (gmail again, ctmail.com, quris.net, vianw.net, macromedia.com, evite.com, sourceforge.net, uu.net, netflix.com, clara.net, go2.pl, yahoo.com, etc.) before trying to send their messages - never mind that if the greeting isn't present it's not clear the remote server is even able to accept the message. It's the modern equivalent of picking up the phone to hear the telemarketer already deep into their spiel.

I know this because we receive a constant stream of outscatter from other hosts, to forged senders in domains we host mail for, which shows that the original messages these other hosts accepted failed all these tests and more. In short, more than a tenth of all email we handle here is the result of other people's failures to live up to basic best practices or the RFCs that define SMTP, period.

There are a lot of things that need to be more widely fixed before we should focus on how to protect the payload; we're lucky any of the messages we're trying to send are delivered at all, in the midst of all this pointless noise and the wretched poverty of basic RFC observance.

Steven Champeon

Re: What Email Needs

2005-10-01T00:53:00.000-07:00

Hi Ed,

Just read (part 1 of) your "What Email Needs" and was wondering...

You pose the question of why so few Email users actually use encryption, despite it being a very trivial exercise in popular MUAs.

Further to your musings, I'd suggest you consider the "but they can read it anyway" factor.  Ever watched _any_ (reputedly) technologically advanced/informed dramatic TV show or movie (think 24, The Matrix, etc)?  Ever noticed how the "good guys" always and bad guys occasionally (in fact, usually only if it is helpful to plot development) can guess any password (usually in less than five tries, or within seconds of some crucial deadline arriving) or break _any_ encryption system (with the application of some suitably "techie sounding" nonsense technology)?

Ever wondered what that does to Joe and Jane Public's perception of the value of using encryption?

...

Actually, I think encryption is used so little in Email mainly because the general populace really does not understand the abysmal _LACK_ of fitness to purpose that modern computers and their software (in their default configurations) provide.  If our car manufacturers had been allowed a fraction of the leeway the computer industry enjoys in terms of providing "sloppy" products, the Pinto might well have been seen as the paragon of safety...  Of course, the difference between cars and general purpose programmable computers of the kind that we seem to insist on foisting on folk is that the latter are immensely (in fact, "immeasurably") more complex, meaning that Joe and Jane Public are never going to have sufficient specialist knowledge to "properly" (and that subsumes "safely") use them.  Cars are just soooo "dumb" in comparison, which is reflected in the level of car-specific knowledge necessary for their widespread, successful use.

This is not a "beat the luser" rant, but more a statement of disgust for the way the computer industry treats its customers...


Regards,

Nick FitzGerald

announcing email-security.net

2005-09-30T23:15:00.000-07:00

I'd like to get feedback on the opening discussion paper at http://email-security.net, which is a technical development forum dedicated to a fresh exploration of the Internet email security issues of today. Comments and paper contributions on the theme of email security are welcome. Papers will be peer-reviewed before publication. Product and service listings are also
welcome, with ad style described in the website.

The blog is here:
http://email-security.blogspot.com/

The Atom feed is here:
http://email-security.blogspot.com/atom.xml

The RSS feed is here:
http://feeds.feedburner.com/email-security

Regards,
Ed Gerck