What Happens in Vegas Really Does Stay in Vegas (Unless It Is Encrypted)

A new Nevada law, S.B. 227, will require entities doing business in that state to beef up their protections of personal information. Previously, we wrote about Nevada’s personal information encryption law. See our blog post here. The current law requires encryption of any personal information transmitted electronically (other than by facsimile). But S.B. 227, which becomes effective on January 1, 2010, will require encryption of all personal information leaving the “logical or physical controls of the data collector,” including electronic data on a “data storage device.”

Here are some key points regarding the new version of Nevada’s encryption law:

What is a “Data Storage Device?”  Included in the definition are: “computers, cellular phones, magnetic tape, electronic computer drives, optical computer drives and the medium itself.”  This is not an exclusive list.

 

What type of Encryption?  Under the old law, any sort of encryption satisfied the encryption requirement, the law did not specify a threshold for compliance.  S.B. 227, however, requires (1)  the use of “encryption technology that has been adopted by an established standards setting body . . . which renders such data indecipherable in the absence of associated cryptographic keys” and (2) “[a]ppropriate management and safeguards of cryptographic keys . . . using standards promulgated by an established standards setting body.”

 

Immunity from damages – If a data collector loses personal information, it is not liable, as long as it complied with the law and the loss did not result from gross negligence or intentional misconduct.  So the new law provides a safe harbor to businesses that follow the more stringent rules.  However, as we noted with respect to the old law, it is not entirely clear who may sue to enforce the law’s provisions.

 

Payment Card Exemption – If personal information is transmitted for use in a payment card transaction then “with respect to those transactions” the data collector need only comply with the Payment Card Industry Data Security Standard (“PCI DSS”).  PCI DSS Requirement 4 requires encryption when the data is being transmitted on an open, public network.  The exact scope of “those transactions” is still unclear, but it is clear that the exemption will not encompass transmissions of personal information that are unrelated to payment card transactions. Payment cards are defined broadly to include almost any card that is issued to an authorized card user and that allows that user to obtain, purchase or receive anything of value.  See NRS 205.602.

 

Telecommunications Provider Exemption – Another interesting addition to the final draft of the law was an exemption for telecom companies that act “solely in the role of conveying the communications of other persons” because these providers are not responsible for the content transmitted using their systems.  This exemption is broad, and applies without regard to the mode of conveyance used, including wireless, voice over Internet protocol (“VOIP”) and other digital transmission technologies.

 

Remaining Questions – Unfortunately, S.B. 227 fails to answer some of our questions about the original law. Specifically, it remains to be seen, among other things, (a) who can enforce this law, (b) whether there is a private right to sue, and (c) what it means for a company to be “doing

business in this State.”

 

Stay tuned!

 

Proskauer summer associate Gary Silber contributed to this post.

Decrypting HHS Guidance on Breach Notification and Security under the HITECH Act: NIST, FIPS, and More

Two months after Congress mandated notification for the breach of unsecured protected health information (PHI), the Secretary of Health and Human Services (HHS) defined what it means to be “unsecured.” As required by Section 13402 of the HITECH Act, H.R. 1, 111th Cong. (1st Sess. 2009) (which was part of the American Recovery and Reinvestment Act of 2009), the Secretary issued guidance and a request for comments on the technologies and methodologies rendering information unusable, unreadable or indecipherable. 74 Fed. Reg. 19006 (Apr. 27, 2009) (to be codified at 45 C.F.R. pts. 160, 164).

As we previously reported, the HITECH Act’s notification requirements for breaches of unsecured PHI apply to entities subject to the Health Insurance Portability and Accountability Act of 1996 (HIPAA), their business associates, and non-HIPAA covered vendors of personal health records (PHR). To constitute a breach, the acquisition, use, access or disclosure of the PHI must “compromise[] the security or privacy of such information.” HITECH Act at §13400(1)(A). The newly issued HHS guidance lists technologies and methodologies that secure information, rendering the data unusable, unreadable, or indecipherable. If PHI is secured according to the HHS guidance, unauthorized access to such information will not trigger the HITECH breach notification requirements, although these breaches may still be subject to state law notification requirements.

This HHS guidance also is to be used to render identifiable health information unusable, unreadable, or indecipherable for purposes of the temporary breach notification requirements that apply to vendors of PHRs, the requirements for which are to be administered by the Federal Trade Commission (which in turn issued proposed regulations, on April 16, 2009, addressing consumer notice for breaches of electronic health information by PHRs).

The HHS guidance provides two methods of securing information for the purposes of the HITECH Act: destruction and encryption. Destruction may secure information that was found in either paper format or in electronic media. In order to satisfy the destruction method, the paper or other hard copy media must be shredded or destroyed such that the PHI cannot be read or otherwise reconstructed. Electronic media must be cleared, purged, or destroyed in accordance with the specifications set forth in National Institute of Standards and Technology (NIST) Special Publication 800-88. 74 Fed. Reg. at 19010.

According to the guidance, the effectiveness of encryption depends on the strength of the algorithm and the security of the decryption key or process. PHI is not secure if the decryption key or process has been breached. Encryption only secures PHI if, in accordance with the HIPAA Security Rule, an algorithm “transform[s] data into a form in which there is a low probability of assigning meaning without the use of a confidential process or key.” 45 C.F.R. § 164.304. Accordingly, the HHS guidance only specifies encryption processes that have been tested and approved by NIST. Data at rest, which is filed or stored in a database, should be encrypted according to the processes outlined in NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices. Encryption processes for data in motion, including that being transmitted or moving through a network, should comply with Federal Information Processing Standards (FIPS) 140-2. Some examples of conforming processes for data in motion are outlined in NIST Special Publications 800-52 (relating to Transport Layer Security (TLS) Implementations); 800-77 (addressing IPsec VPNs); and 800-113 (SSL VPNs), and may include others which are FIPS 140-2 validated.

Since the technologies and methodologies in the guidance are intended to be exhaustive, the Secretary of HHS sought comments regarding additional technologies or methodologies for inclusion in future guidance. HHS also requested comments on various other related issues, including instances when specified technologies and methodologies would fail to secure information, how the federal notice requirements affect existing state law requirements, and whether and how limited data sets (created in accordance with the HIPAA Privacy Rule) could be included in this guidance. This HHS guidance will be closely watched not only as it relates to federal law, but also as to how it informs state law interpretations. Encryption remains undefined under state law, and the HHS guidance provides a potentially important source of interpretation.

This guidance will apply to breaches that occur at least thirty days after publication by HHS of the interim final regulations on breach notification (which have not yet been issued). Any modifications to this guidance based on comments received are expected to be made prior to or concurrent with those regulations.

Proskauer summer associate Katrina McCann contributed to this post.

Massachusetts Regulators Postpone Compliance Deadline and Issue Revised ID Theft Regulations

On Thursday, the Massachusetts Office of Consumer Affairs and Business Regulation (“OCABR”) revised and postponed -- for the second time -- its comprehensive data security regulations. The new deadline for all covered entities to achieve full compliance with the Massachusetts regulations is January 1, 2010. This fixed deadline replaces a tiered-compliance schedule established by OCABR in November 2008 that would have given covered entities until May 1, 2009 to install certain data security safeguards, including encrypting personal information on laptops, and until January 1, 2010 to implement more aggressive security measures. (See our prior post here.)

Responding to the concerns of the regulated community, the OCABR’s revised regulations, 201 CMR 17.00, do not require covered entities to obtain written certification of compliance with the regulations from third party service providers handling personal information on their behalf. Instead, covered entities need only take steps to verify that third party service providers are able to, and do, employ the kind of personal information security measures required by 201 CMR 17.00. The revised regulations are otherwise nearly identical to the OCABR’s earlier version, which is described here.

In the OCABR’s Thursday press release, Undersecretary Daniel Crane expressed the importance of the new regulations to Massachusetts consumers and the need for businesses to take steps toward compliance. As to the revised compliance timeframe, Crane said “[w]e understand the impact of the current business environment, and feel this is an appropriate timeframe for companies to implement the necessary protections.”

UK Court Parts with US Court regarding Compelled Disclosure of Encryption Keys

On October 9, in the case R v. S and A [2008] EWCA Crim 2177, the Criminal Division of the England and Wales Court of Appeal held that requiring criminal defendants to disclose an encryption key allegedly protecting criminal materials does not violate the privilege against self-incrimination under U.K. law or Article 6 of the European Convention of Human Rights.  The U.K. court’s ruling is at odds with Magistrate Judge Jerome J. Niedermeier’s ruling on a similar issue in the District of Vermont, In re Boucher, No. 06-mj-91, 2007 WL 4246473 (D. Vt. Nov. 29, 2007).

R v. S and A involved two defendants whose encrypted laptops were seized in the course of an anti-terrorism investigation. The authorities located several suspicious files that they could not open due to encryption. Pursuant to section 53 of the Regulation of Investigatory Powers Act of 2000, the defendants were served with a notice requiring them to reveal the encryption key. Defendants refused and applied to stay the notices.

As the United Kingdom lacks a written constitution, the privilege against self-incrimination is a common law principle.  It is not absolute and is subject to numerous statutory exceptions. The court did not address this issue at length, however, because it found that requiring the defendants to reveal an encryption code did not trigger the privilege.  The court found that the encryption key existed "independent of the will of the subject," much like the key to a drawer.  Even though the defendants created the key initially, "once created, the key to the data, remains independent of the appellant’s ‘will’ even when it is retained only in his memory, at any rate until it is changed."  The court noted that while evidence of the defendants’ knowledge of the encryption key could itself be incriminating, the trial judge could preclude such evidence and was a minimal intrusion into the right against self-incrimination as compared to national security.

In In re Boucher, Magistrate Judge Niedermeier considered Boucher’s motion to quash a subpoena requiring that he produce all documents reflecting any passwords used or associated with his computer.  At hearing on the motion, prosecutors offered to allow Boucher to enter the code without any monitoring, rather than to reveal it outright, and further offered not to comment at trial upon his knowledge of the password.  This was not protective enough for the Magistrate, as discussed below.

Unlike the British court, the Magistrate found that requiring Boucher to reveal or enter the encryption code he used to protect his alleged child pornography triggered his Fifth Amendment rights, which prevent compelled disclosure of incriminating information of a testimonial nature. See Fisher v. United States, 425 U.S. 391, 408 (1976).  The Magistrate cited United States v. Doe, 465 U.S. 605, 612 (1984) and Doe v. United States, 487 U.S. 201, 209-212 (1988), for the premise that the mere act of producing a non-testimonial document or object can be testimonial where it reveals a defendant’s knowledge.  The Magistrate drew upon the same key/locked drawer metaphor as the British court, but citing Doe v. United States at 218, held that unlike surrendering a key, disclosing a password reveals the contents of one’s mind and is therefore testimonial.  In re Boucher, 2007 WL 4245473, at *4.  Magistrate Judge Niedermeier’s ruling quashing the subpoena was appealed to District Judge William K Sessions III and, according to the PACER docket, has been pending since May.

Leaving Las Vegas . . . IF Encrypted

A Nevada law requiring encryption of customer personal information goes into effect on October 1, 2008. See Nev. Rev. Stat. § 597.970 (2007). While the legislation is short in length, it is potentially wide-ranging in scope. In particular, the legislation requires any "business in this State" to encrypt an electronic transmission (other than via facsimile) of "any personal information of a customer" to "a person outside of the secure system of the business unless the business uses encryption to ensure the security of the electronic transmission." Id.

 

What Is Personal Information?Nevada law defines "personal information" to mean a natural person’s first name or first initial and last name in combination with the person’s: social security number; driver’s license number or identification card number; and/or account, credit or debit card number in combination with any security code, access code, or password that would permit access to the person’s financial account. Nev. Rev. Stat. § 603A.040 (2007). Natural person is not limited to Nevada residents.

 

 

 

Encryption means "the use of any protective or disruptive measure, including, without limitation, cryptography, enciphering, encoding or a computer contaminant, to:

      1.  Prevent, impede, delay or disrupt access to any data, information, image, program, signal or sound;

      2.  Cause or make any data, information, image, program, signal or sound unintelligible or unusable; or

      3.  Prevent, impede, delay or disrupt the normal operation or use of any component, device, equipment, system or network."

Nev. Rev. Stat. § 205.4742 (2007).

 

 

Some open questions remain, which include:

 

How "business in this State" will be interpreted and applied.

The meaning of "customer."

The meaning of "secure system of the business."

Enforcement of the legislation. The law does not specify how and by whom enforcement happens. Similarly, it does not identify a penalty for failure to comply with the encryption requirement.

Does it mean something more than a business’s local area network?
It is not limited to Nevada residents. Does "customer" mean that the law will only apply to individuals who purchased goods or services from a business?
Will the encryption requirement be limited to only business operations in Nevada?

 

 

Open Questions

 

 

What Is Encryption?