The meet-up is centered around the new XML Advanced Electronic Signatures (XAdES) support in Office 2010. In my opinion, this is a great step forward for Office’s digital signature support, as XAdES provides the appropriate XML schemata to embed timestamps, revocation information and countersignatures within a digital signature on a document. Timestamp and embedded revocation support are two of the chief advantages that Acrobat digital signatures have held over Office for the past several years. Finally enabling this functionality will allow Office to compete with Acrobat on a more even playing field in terms of allowing robust, more auditable signature workflows.

I’m interested in seeing what updates, if any, have been made to the Office digital signature interface to support this new functionality. In current and previous versions of Office, digital signature validation, from a UI perspective, has been abysmal. There has simply been no way to determine *why* a signature is judged as invalid by Office when there are myriad possible causes for such a failure. For example, a signature may be invalid due to an altered document, which is far more of a concern than a signature being invalid due to revocation data being unavailable because the validation was performed offline. These circumstances can lead to different trust levels from the user.

It remains to be seen how well the XAdES support is implemented, but I’ll tentatively state, sight-unseen, that this is at least a step in the right direction.

http://eprint.iacr.org/2010/006.pdf Is it time to deprecate 1024bit RSA for, say, 1276bit? (2048 has perf issues.)

The link Dan provided is a research paper which reports the successful factorization of the 768-bit number from the original 2001 RSA challenge. I responded to him that NIST had already deprecated the use of 1024-bit RSA in the government, and it was time for industry to follow suit. Since I posted that, I’ve been surprised that a number of people don’t understand the upcoming changes in key lengths and algorithm strengths that have been mandated by NIST. So, this post offers some information about why I can confidently say the U.S. government has deprecated certain algorithms and key lengths.

What is being deprecated?

• Hashing: 160-bit SHA-1 (note: MD4/MD5 was never an “acceptable algorithm” to the government, and should already be deprecated)
• Signatures: 1024-bit DSA, 1024-bit RSA, 160-bit ECDSA
• Encryption: 80/112-bit 2TDEA (two key triple DES)

When are they deprecated?

• Hashing: for all hashes generated after 12/31/2010
• Signatures: for all signatures generated after 12/31/2010
• Encryption: for any information that needs to remain confidential after 12/31/2010

Where does it say they are deprecated?
While a little more complicated, there is a direct chain of requirements and documents which point to this. The government has unfortunately not made this as obvious and direct as it should be in order to get the maximum buy-in and cooperation from industry. This post is my attempt to help put the pieces together.

• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems requires “Federal agencies must meet the minimum security requirements as defined herein through the use of the security controls in accordance with NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, as amended.”
• NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, indicates that information systems which need to protect information using cryptography must “produce, control, and distribute symmetric cryptographic keys using [Selection: NIST-approved, NSA-approved] key management technology and processes” and references NIST Special Publication 800-57.
• Section 5.6 of NIST Special Publication 800-57 Part 1, Recommendation for Key Management contains Table 4 indicating the above deprecations I list.

So, here’s the bottom line: 1024-bit algorithms and SHA-1 shouldn’t be used after the end of this year. The government has mandated it, and industry should follow along. It is time — perhaps well past time — to start testing your cryptographic systems, applications, and tools with 2048-bit keys and SHA-2.

The idea is fairly simple. Many (most?) large enterprises already manage their users and systems using Active Directory.  Geneva allows publishing the components of your Active Directory required for doing identity federation on the Internet.  The publishing is performed in a standards-compliant way (using WS-* and SAML 2.0) and allows it to be used for claims between enterprises.

…the issue of Identity Management, Username and Password proliferation, and cross-company collaboration is an issue that has hindered true (and secure) data availability and collaboration in the Life Sciences industry.  Perhaps now we can get the Identity Management issue behind us and move on.

Whether or not Geneva becomes the one standard way to allow interoperable identity management across multiple enterprises in the life sciences space, it is clearly going to lower barriers between organizations and increase our trustworthiness in digital identities.

The IRS has developed six new security and privacy standards to better protect taxpayer information collected, processed, and stored by Authorized IRS e-file Providers participating in Online Filing of individual income tax returns.

These new standards are based on industry best practices and are intended to supplement the Gramm-Leach-Bliley Act and the implementing rules and regulations promulgated by the Federal Trade Commission.

So, what does this mean for the average online tax-filer? It means that the company that you e-file through (TurboTax, efile, TaxACT, etc) will have to adhere to stricter policies and standards regarding the handling of customer information.

Most of these policies seem to be standard precautions from a security perspective. However, I can certainly understand how a provider may be unfamiliar with the risk involved with handling such sensitive information. The 6 suggestions are mostly focused on tightening the security around the provider’s web presence: they call for strong EV SSL certificates (SSL 3, 1024-bit RSA), weekly third-party vulnerability scans, a written privacy policy, CAPTCHA-like capability, an ICANN domain name from a registrar located in the USA, and the prompt reporting of security incidents.

These are all good policies and are definitely a step in the right direction. The only issue I see is that these “standards” are currently optional. Although the IRS suggests that providers follow them, they aren’t required yet. In a way, this defeats the purpose of having them in the first place.

According to this letter(pdf) from Yahoo to Senators Durbin and Coburn:

Principles on Freedom of Expression and Privacy [...] provide direction and guidance to the ICT industry and its stakeholders in protecting and advancing the enjoyment of freedom of expression and privacy globally. The Principles describe key commitments in the following areas: Freedom of Expression; Privacy; Responsible Company Decision Making; Multi-Stakeholder Collaboration; Governance, Accountability & Transparency

Along with censorship and freedom of speech, the idea was also to provide general requirements for privacy. The idea also calls for a way to determine if a company is compliant with the code and a way to hold companies accountable if they violate it.

This is important because it shows that some of the most relevant internet-based companies are taking the rights of their users seriously. So seriously, in fact, that they are willing to sponsor a set of guidelines that help other companies protect THEIR user’s rights as well. If more companies get on board, this could be a step in the right direction in helping to strengthen the trust between service provider and user.

I would suspect that this is a common situation for smaller companies. They decide that they’re not happy with their current registrar for whatever reason, and switch. Unfortunately, not understanding how computers find each other and buying into the “complete hosting solution” packages offered by many registrars. In an effort to prevent other small companies from suffering the same fate, I present DNS, whois, and hosting for dummies.

When you decide to set up a website, there are really three services at play:

1. Hosting – this is where the files that makeup your website reside
2. Domain Name ownership – this is where you buy a domain name (whatsit.com)
3. Domain Name Service – this is buying a service to map www.whatsit.com to your actual website

Computers don’t use hostnames to find each other, they use IP addresses, which are not human friendly. The Domain Name System (DNS) service maps all of the human readable hostnames to computer friendly IP addresses.

When you buy a domain name, you buy from a registrar. GoDaddy.com, Register.com, and Network Solutions are some of the larger registrars. What they do is set up DNS in the top level domain (.com, .org, etc) for you. All that does is say that you own it, and that you’ll be providing your own DNS servers for that domain. You must also tell your registrar who is providing DNS services for you. Oh, you don’t have a DNS service provider yet? Your registrar will helpfully use their own DNS servers for you until you do. These servers will point to some kind of advertising page if someone goes to http://whatsit.com. Don’t worry, unless you’re providing your own DNS services (and if you’re buying hosting, you probably aren’t), you can’t get DNS services until you’ve bought the domain, so you’ll have that ad page there for an hour or so at least.

Next, you’ll buy your hosting, because you’ll need to be able to give them your domain name, and they’ll need to give you an IP address. Once you have the IP address of your server, you can go buy DNS services. However, you’ll probably want to work with your hosting provider to somehow get your website content to their servers.

All of the registrars can provide DNS services (for an extra fee), but there are a few free or inexpensive ones (Granite Canyon is one of my favorites for free, and DynDNS can’t be beat for low cost). You’ll need to give the DNS provider your domain name, and the hostname and IP address of your web server (given to you by your hosting provider). They’ll give you a list of name servers. Now you have to give this list of name servers to your registrar and, finally, people will be able to get to your content on your web site.

As you can see, there are a lot of moving parts, so it’s really common to just let one entity (usually the registrar, but sometimes your hosting provider) handle it all for you. However, if you have more DNS entries, such as for a mail server, the registrar or hosting provider may not know about them, so switching all of these services at once can turn into lost DNS entries. Because, now, your new registrar is listed as the DNS service for your domain, but it doesn’t know about all those other entries you’ve added over the years, and they are simply gone if you didn’t keep a backup somewhere. If these entries aren’t in your DNS, other computers can’t find your computer(s) any more, causing a denial of service (DoS). Even if you choose to have one entity arrange all of these services for you, knowing how it all works will be useful to figuring out what’s wrong when things break.

The framework is designed to establish a common set of “best practices” that should be followed by applications and services that handle, process, or store personal health-related data online.

According to Markle :

The framework …includes four overviews and 14 specific technology and policy approaches for consumers to access health services, to obtain and control copies of health information about them, to authorize the sharing of their information with others, and sound privacy and security practices.

I think this is a great step in the right direction. With the increase in instances of personal health records being stored electronically, a framework for keeping things as secure as possible is essential.

Microsoft HealthVault and Google Health drew some attention from the security industry when they were announced; consequently, issues of privacy and security were raised. As more and more providers and insurance companies are experimenting with making health records available to both doctors and patients via the Internet, these same issues will become more and more important.

It is good that they are getting together to lay down some “ground rules.”

As standards go, the SAFE specification is relatively simple, as it is mainly a set of guidelines for how signatures must be created and validated as opposed to a format specification. The XAdES standard, in contrast, is a more formal XML-based digital signature specification that can provide timestamping and embedded revocation information. A few forms of XAdES signatures may
be made SAFE compliant, but the SAFE specification does not entirely overlap the XAdES standard; not all XAdES signature forms are SAFE compliant.

XAdES, specifically XAdES-X-L and XAdES-A, seems well suited for use in various CDISC [Clinical Data Interchange Standards Consortium] standards, including the Operational Data Modeling standard. The ODM standard provides an XML schema for maintaining clinical trial results.

I don’t really have a problem with the proliferation of standards in the health care IT space so long as these standards aren’t redundant, and in this particular case they aren’t. However, the more standards that are devised, the more expensive it’s going to become for applications to be compliant, especially when there are standards that are tangentially related, and then more standards have to be created to formally correlate them.

Next week, however, Exostar will launch a new capability, the Federated Identity Service, that does the process of “credentialing” on behalf of Exostar’s members, ensuring that individuals that attempt to use the systems of the community or its members are who they say they are — and are authorized to use the systems they are trying to access.

The concept behind federated identity is a simple one. Leverage existing investments providing identification / authentication of users, and build an authorization structure that works across multiple applications, systems, companies, and vertical markets. The U.S. Government has their E-Authentication initiative, there are also the Shibboleth, Liberty Alliance, and WS-Federation standards. Tons of companies have interests and products in this area including Oracle, Microsoft, Novell, Sun, Symlabs, Ping Identity, CA, Siemens, IBM, etc. Other industry groups are looking to stand up their own federated identity infrastructures, similar to that performed by the aerospace industry.

The fortunate thing is that the SAML 2.0 standard seems to be the standard that most products, standards, and organizations are moving toward. However, just because everyone settles on SAML doesn’t mean that everyone will interoperate. I suspect there still needs to be some federating of the federation standards before more universal adoption is achieved.

And now let’s look forward 5-10 years toward a future where the entire Internet shares a federated identity infrastructure; where you can use one single CardSpace card and/or OpenID login to get into your email, bank accounts, paypal, social security benefits, buy things from Amazon, and forward your mail. Now, an identity thief needs to steal just one username and password and everything goes up in smoke.

One interesting point that was made was that if there is a security patch available for a validated system, and that patch has not been applied to that system, then the system is not considered by the FDA to be compliant. However, full qualification tests must be run and documented while applying the patch, which takes time. The issue that this creates is that security patches are released frequently enough and validation testing takes long enough such that validated systems become a bit of a mess to manage.

So, what can be done about this? One important step that was discussed is this: since the part 11 requirements only cover patches that affect the validated part of the system, any security updates released for non-validated portions of the platform should be pushed immediately. For example, a printer driver update for a printer that will never be used by a web server machine can be applied without testing, since it does not affect the validated functionality of the system. However, this just makes the problem a little more manageable; it doesn’t eliminate it completely.

If a validated system is out of compliance in an unpatched state but also out of compliance when a patch is applied without formal testing, I’m of the opinion that a “patch first, test second” approach should be taken. True, this may break some application functionality, but I would much rather have a broken application than an insecure one handling my personal data. [This assumes that compliance is taken as a binary data point: compliant or not-compliant. If there are degrees of non-compliance, I may change my mind about this.]

Aside from that, the only other option I can think of is to throw more resources at patch validation so security updates can be rolled out quickly. But, as we all know, security is not a value-add, so the goal is typically to throw as little money at security services as possible so as not to lose customers or run afoul of the law.