Entries in White Papers (6)

Tuesday
Aug232011

Cloud Security Risk Agreements for Small Businesses

Isaac Potoczny-Jones <ijones@galois.com>

PDF version.

ABSTRACT
Cloud computing can be particularly beneficial to small businesses since it can decrease the total cost of ownership for IT systems. Unfortunately, one of the major barriers to adoption of cloud services is the perception that they are inherently less secure, exposing the organization to unacceptable risk. There are standard processes for managing security risk that can help businesses make trade-off decisions, but these processes currently cannot be applied to cloud computing since the security details of cloud services are not typically available to small businesses. This lack of information leads to a lack of trust: small businesses cannot evaluate the security of cloud services. This paper proposes an approach for cooperation between cloud vendors and small businesses based on the NIST Risk Management Framework. Security Risk Agreements would address the lack of trust so that small businesses can confidently adopt cloud services, benefiting both small businesses and cloud vendors.

1.    INTRODUCTION
Cloud computing is the concept of offering remote network access to a set of IT resources [20], and it has the potential to be very valuable to small businesses since it can decrease the total cost of ownership of IT systems. However, one of the major barriers to adoption of cloud services is the perception that they are inherently less secure, exposing the organization to unacceptable risk [11]. This perception is based on the existence of vulnerabilities that are unique-to or amplified-by typical cloud-based architectural approaches and since cloud services are hosted remotely [16] [19] [20].

Risk-based security analyses such as NIST’s Risk Management Framework [23] are a widely-adopted method for making security decisions. Such a risk-based analysis of cloud services would allow a small business to make cost-benefit decisions about whether to deploy cloud services since they could analyze the vulnerabilities and implement security controls. However, the security details of cloud services are not typically available to a small business. This lack of information leads to a lack of trust: small businesses cannot evaluate the security of cloud services.

This paper proposes that cloud service providers should offer a Security Risk Agreement (SRA), which is a kind of Service Level Agreement (SLA) tailored to providing small businesses the information they need to evaluate whether a certain cloud service will meet their security requirements.

Increased trust will increase adoption, benefiting both the business and the cloud vendors. This type of agreement would address the widespread lack of trust in cloud security through an explicit and mutual understanding, based on a widely-adopted risk framework.

2.    BENEFITS TO SMALL BUSINESSES
Cloud computing is gaining attention since it is believed that it increases flexibility and decreases the cost of IT services. NIST defines cloud computing as, “a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [20].”

The US federal Chief Information Officer Vivek Kundra has argued that cloud computing is economical, flexible, can be rapidly implemented, can improve consistency in service, can be more energy efficient, and can increase an organization's ability to focus on its mission since it can spend less time and fewer resources on information technology [18].

For example, small Internet-based businesses which cannot predict their bandwidth, storage, and CPU utilization might appreciate the flexibility that services like Amazon's EC2 system provide since they can automatically scale based on the required usage. Furthermore, services like Google Docs can provide capabilities, like word processing, that are enhanced with collaborative aspects since multiple users can modify a document simultaneously. For small user bases such cloud-based services are often free.

Cloud vendors and NIST both argue that cloud computing has some security advantages, and indeed can be more secure in some cases since, for instance cloud vendors have dedicated security teams [20]. For instance, Google has deployed multi-factor authentication [9] which increases the security of the login process.

All of these elements should make cloud computing attractive to small businesses, since they can save on investment in IT and security specialists.

3.    CLOUD RISK MANAGEMENT
As with any technology, such benefits are partly offset by the existence of risks, and in particular for cloud computing, security tops the list of concerns for most organizations [11].  Risk-based security analyses are a widely-adopted method for making security decisions and are required for federal systems covered by FISMA [23] and health-care related systems covered by HIPAA [29]. A risk-based analysis of cloud services would allow a small business to make cost-benefit decisions about whether to deploy cloud services since they explicitly weigh the impact of potential security problems against the cost of mitigating those problems. Processes for managing security risk have been developed by a number of organizations, but these processes are of limited applicability in cloud computing, since cloud vendors do not supply risk information about their services.

One risk analysis process is the Risk Management Framework (RMF) which is outlined in detail in NIST's documentation [23] and involves understanding the impact of a loss of Confidentiality, Integrity, or Availability (CIA) to an organization's data or systems. The impact of such a loss is categorized as low, moderate, or high, depending on the reputation, financial, and human costs of an event. For instance, a high impact security event might involve the loss of human life [21]. Based on this impact assessment, the process goes on to define steps for identifying vulnerabilities, selecting and deploying security controls to manage those vulnerabilities, and ongoing assessment and monitoring of their effectiveness.

When an organization stores its data in a cloud-based system, that system becomes a part of its IT infrastructure since a CIA failure in a cloud system would impact that organization's data. Furthermore, the cost savings of cloud computing can be offset by the level of risk it imposes. Therefore, a small business's cost/benefit analysis should include a risk analysis of those systems before moving the organization's data to them.

4.    VULNERABILITIES AND SHARING
Cloud computing involves a number of vulnerabilities that are not present in traditional environments where an organization physically controls its own computing resources and does not share hardware or software resources with other organizations or the general public. The level of sharing between customers can vary greatly depending on the service. For the sake of argument, let's say that for a given level of sharing, there is some possibility that a malicious individual is sharing resources with an organization that wishes to protect its data. A greater level of sharing implies a higher degree of risk (all other things being equal) since the pool of users is more likely to include malicious users. Small businesses, whose resources are subject to a high degree of sharing, are therefore subject to high risk.  This section outlines different sharing models (which are not mutually exclusive) and related vulnerabilities:

4.1.    Cloud Deployment Types
NIST defines three categories of cloud deployments: private, community, and public, and these each imply different types of sharing [20]. Private clouds are those that are owned or leased by an enterprise, and so involve the least amount of sharing. These are likely outside the scope of what a small business can afford, so will not be discussed further.

Community clouds are those that are shared by a set of organizations with some mutual trust. For example, Google's “Apps for Government” system has a separate cloud for organizations that are required to be FISMA compliant [12].  This addresses a vulnerability that Mell & Grance point out: that data stored in the cloud could be subject to foreign governments' legal actions [20]. Google addresses this by storing government data only within the US [17], but it doesn't make that guarantee for public cloud customers like small businesses.

Public clouds are available to the general public and so involve the most sharing. These are the types of systems that most small businesses would use. The following sections outline other sharing models and related vulnerabilities that can apply to private, community, or public clouds. These vulnerabilities are probably more likely to have an impact in public clouds since they have a larger user pool, some of which might include malicious users.

4.2.    Multi-Tenant vs. Dedicated Tenant
Multi-tenant architectures allow multiple customers to use the same database and application instances [5]. Although there are mitigations, such architectures can lead to SQL injection vulnerabilities where malicious users issue queries against the database holding sensitive information. Furthermore, errors in access control enforcement can lead to inadvertent disclosure of data [26]. Dedicated tenant services host only a single customer, and so some such vulnerabilities might be more difficult, but this can come at the cost of performance.

4.3.    Virtualization Vulnerabilities
Virtualized systems run multiple virtual machines on a single physical host, and Gartner argues that such virtualized servers will be more vulnerable than physical servers for the next few years as organizations learn more about securing their systems [10]. One vulnerability is that confidential information can be leaked when a malicious user is able to execute a virtual machine on the same Local Area Network. For instance, researchers have demonstrated the ability to estimate traffic rates, perform side-channel attacks in order to extract key material, and use timing channels to send covert data between machines [27]. Another vulnerability is that if a malicious user is running a virtual machine on the same physical machine, there's some potential that they can execute some code that will give them control over the operating system that is executing all of the virtual machines. This has been demonstrated in practice [28].

4.4.    General Vulnerability Classes
Other vulnerabilities are not necessarily specific to the method of deployment. Mell and Grance outline several general classes of security challenges [20] which include:

Customers must trust the cloud vendor’s security model. For instance, errors in the cryptographic implementation of cloud services could result in a loss of confidentiality of customer data as in [25]. In order to trust the cloud vendor’s security model, customers first need to understand the security claims made by the cloud vendor. For instance, the Dropbox cloud storage service has come under criticism for how it expressed security claims about its use of encryption, leading some customers to believe their data was cryptographically protected from Dropbox insiders [30] and resulting in an FTC complaint [31].

Customers cannot necessarily respond to audit findings, for instance, when a Linux vulnerability affecting EC2 was discovered [3] administrators could not address the issue until Amazon released corrected kernels [24].

Customers can have trouble obtaining support for investigations, for instance, if a security expert wishes to test their own EC2 service for vulnerabilities, they must request permission from Amazon, and certain types of testing are not permitted since it would affect other customers' shared resources [4].

Proprietary implementations cannot be examined by the customer, for instance, one of the above vulnerabilities was visible to the public, and so was discovered by a customer, demonstrating the strength of transparency [25].

Customers lose physical control of the IT systems, for instance, data hosted in a foreign country is subject to their laws. Even laws in the US are unfavorable since, as is pointed out in [6], cloud vendors can be subpoenaed for a customer's data, whereas if they stored the data themselves, a warrant would be required, which has a higher burden of proof.

5.    BARRIERS TO RISK-BASED ANALYSIS
Thus far this paper has outlined cloud computing's potential benefits to small businesses, the necessity for small businesses to perform risk-based security analyses for cloud services, and the vulnerabilities that cloud computing is subject to. In order for small businesses and cloud vendors to reap the benefits of a shift to cloud services without small businesses having to sacrifice their ability to perform such analysis, cloud vendors should provide service-level agreements that include risk-based guarantees about the level of security of their infrastructure.

Cloud vendors understand the necessity of risk analysis, at least in their engagements with the US federal government. Google and Microsoft both already provide FISMA compliant cloud services for government clients [8] [12], which involves risk-based analysis, but no such commitment is made to the general public. Cloud vendors also provide SLAs relating to performance and availability, and these agreements have reimbursement clauses which offer financial guarantees [2] [14], but no such guarantee is provided with regard to confidentiality and integrity.

Cloud vendors also recognize the importance of conveying the security of their infrastructure [1] [7] [15], likely because they understand that security is a major barrier to adoption. However, while these assurances are some comfort, they do not come with a guarantee, and are insufficient for risk management.

6.    SECURITY RISK AGREEMENTS (SRAs)
When a small business adopts cloud computing, they are outsourcing part of their IT infrastructure, and they therefore also must outsource some aspects of their risk management. A Security Risk Agreement should include principles of transparency and communication between the cloud vendor and the small business, the definition of security incidents and their severity, what level of guarantee the vendor is offering against incidents, and the consequences of a loss of confidentiality or integrity (availability being well defined in current SLAs). With that in mind, this section briefly outlines the steps of the Risk Management Framework [23] and what roles the small business and the cloud vendor play in each step.

Step 1: Categorize the information system. In this step, the small business acts as the Information Owner/Steward and identifies the impact of a loss of confidentiality, integrity, or availability for its data: low, moderate, or high. The cloud vendor acts as the Information System Owner and will declare what level of impact their system can be authorized to handle. Some cloud vendors might only be trusted to handle low-impact data, but can potentially provide this service at a lower cost than a vendor who can handle moderate- or high-impact data.

Steps 2-3: Select and implement security controls. In these steps the set of security controls (mitigations) from NIST 800-53 [22] are selected and implemented by a combination of the cloud vendor and the small business. NIST divides security controls into a number of families, and within each family, some controls will be more naturally the accountability of the business and some of the cloud vendor. Since each business has unique security needs, each will likely want to identify a baseline set of must-have security controls and select vendors which are known to implement those security controls. Furthermore, the business might be required to implement some security controls in order to make up for a lack of controls from the cloud service (e.g. implementing encryption in the transport layer to make up for the lack of a virtual private network). For each family of security controls, one party bears the primary accountability for selecting and implementing the controls from that category, and that accountability is summarized in Table 1.

Table 1. Proposed Primary Accountability for NIST 800-53 Security Control Families

Primary Accountability Falls To Families of Security Control
The small business awareness and training, planning, personnel security, and system and services acquisition
The cloud vendor configuration management, contingency planning, identification and authentication, incident response, maintenance, physical and environmental protection, system and communications protection, and system and information integrity
A neutral third party security assessment
Accountability is split roughly equally access control, audit and accountability, media protection, and risk assessment

 

Step 4: Assess the effectiveness of the security controls. NIST emphasizes the importance of the independence of a security assessor. Since this assessment can largely be shared among all the customers of a cloud service, and since the details of some identified weaknesses (arguably) should not be made known to the general public, a neutral third party should be available to assess the controls and to communicate the high-level results, including the level of residual risk, to the small businesses. Furthermore, businesses must be permitted to perform their own assessments since they might have unique security concerns.

Step 5: Authorize the information system. The cloud vendor should provide a plan to its customers to correct any weaknesses. The small business must be accountable for determining the level of risk to the organization and determining if that level of risk is acceptable.

Step 6: Monitor security controls. Ongoing monitoring is the shared responsibility of the cloud vendor, the small business, and the security assessor. A security impact analysis of proposed changes must be performed by the cloud vendor and reported to the small business so that the business can assess the impact of that change on its corporate risk. Furthermore, businesses should be notified in advance of any change in security and either have the option to opt-out of a change or be given time to transition to a different vendor.


7.    CONCLUSION
At the same time that cloud computing is becoming ubiquitous, computer security is increasingly a concern for all businesses large and small. However, current service-level agreements between small businesses and cloud vendors do not allow for risk-based analysis of security by those businesses. This paper discusses both the value and the vulnerabilities of the shift to cloud computing and argues for a new practice in cloud business arrangements: the Security Risk Agreement. Such agreements will provide both parties with a clear understanding of their roles and accountabilities to one-another. This will help to avoid the kinds of mismatched expectations about security controls that can hurt both cloud service providers and their customers, as was the case regarding technical details of Dropbox’s encryption. This paper provides an initial overview of the roles of each party in the context of NIST's Risk Management Framework. Security Risk Agreements address the major barrier to adoption of cloud computing: business's trust that their data will be handled with an appropriate level of security.


8.    REFERENCES
[1]     Adams, S. 2010. Microsoft’s Cloud Infrastructure – FISMA Certified. FutureFed. http://blogs.msdn.com/b/uspublicsector/archive/2010/12/03/microsoft-s-cloud-infrastructure-fisma-certified.aspx.

[2]    Amazon. 2007. Amazon S3 SLA. Amazon Web Service http://aws.amazon.com/s3-sla/.

[3]    Amazon. 2009. Linux kernel vulnerability in certain EC2 AMIs.  Amazon Web Services. http://aws.amazon.com/security/security-bulletins/linux-kernal-vulnerability-in-certain-ec2-amis/.

[4]    Amazon. Penetration testing [policy]. Amazon Web Services. http://aws.amazon.com/security/penetration-testing/.

[5]    Bezemer, C. P. and Zaidman, A. 2010. Multi-tenant SaaS applications: maintenance dream or nightmare?. Proceedings of the Joint ERCIM Workshop on Software Evolution (EVOL) and International Workshop on Principles of Software Evolution (IWPSE), New York, NY, USA, pp. 88–92.

[6]    Brenner, S. W. 2006. Cybercrime and the U.S. criminal justice system. in Handbook of information security, vol. 2, H. Bidogli, Ed. NY, NY: John Wiley & Sons, Inc.

[7]    Dropbox. 2011 How secure is Dropbox? https://www.dropbox.com/help/27.

[8]    Estberg, M. 2010. Microsoft’s cloud infrastructure receives FISMA approval. Global foundation services blog. http://blogs.technet.com/b/gfs/archive/2010/12/02/microsoft-s-cloud-infrastructure-receives-fisma-approval.aspx.

[9]     Feigenbaum, E. 2010. A more secure cloud for millions of Google Apps users.  Official Google Enterprise Blog. http://googleenterprise.blogspot.com/2010/09/more-secure-cloud-for-millions-of.html.

[10]    Gartner. 2010. Gartner says 60 percent of virtualized servers will be less secure than the physical servers they replace through 2012. http://www.gartner.com/it/page.jsp?id=1322414.

[11]    Gens, F. 2008. Cloud Services User Survey, pt.2: Top Benefits & Challenges.  http://blogs.idc.com/ie/?p=210.

[12]    Google. FISMA-certified cloud applications for government. Google Apps for business. http://www.google.com/apps/intl/en/government/trust.html.

[13]    Google. Google Apps for business online agreement http://www.google.com/apps/intl/en/terms/premier_terms.html.

[14]    Google. Google Apps service level agreement. http://www.google.com/apps/intl/en/terms/sla.html.

[15]    Google. Software-as-a-service has built-in security advantages.  Google Apps for business. http://www.google.com/apps/intl/en/business/infrastructure_security.html.

[16]    Gruschka, N and Jensen, M. 2010. Attack Surfaces: A Taxonomy for Attacks on Cloud Services. Proceedings of the 2010 IEEE 3rd International Conference on Cloud Computing, Washington, DC, USA, pp. 276–279.

[17]    Krishnan, K. 2010. Introducing Google Apps for Government. Official Google Blog. http://googleblog.blogspot.com/2010/07/introducing-google-apps-for-government.html.

[18]    Kundra, V. 2010. State of Public Sector Cloud Computing. Chief Information Officers Council.

[19]    Li, H. C., Liang, P. H, Yang, J. M, and Chen, S. J. 2010. Analysis on Cloud-Based Security Vulnerability Assessment. E-Business Engineering, IEEE International Conference on, Los Alamitos, CA, USA, 2010, vol. 0, pp. 490-494.

[20]    Mell, P and Grance, T. 2009. Effectively and securely using the cloud computing paradigm.

[21]    National Institute of Standards and Technology. 2004. Federal Information Processing Standards Publication, Standards for Security Categorization of Federal Information and Information Systems (FIPS PUB 199).

[22]    National Institute of Standards and Technology. 2009. Recommended Security Controls for Federal Information Systems and Organizations (SP 800-53 Revision 3).

[23]    National Institute of Standards and Technology. 2010. Guide for applying the risk management framework to federal information systems (SP 800-37).

[24]    ObReiman. 2009. Kernel vulnerability affects EC2: NULL pointer dereference. AWS Developer Forums https://forums.aws.amazon.com/message.jspa?messageID=142144.

[25]    Percival C. 2008. AWS signature version 1 is insecure. Daemonic Dispatches. http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html.

[26]    Rane, P. Securing SaaS Applications. Information Systems Security.http://www.infosectoday.com/Articles/Securing_SaaS_Applications.htm.

[27]    Ristenpart, T., Tromer, E., Shacham, H., and Savage, S. 2009. Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds. Proceedings of the 16th ACM conference on Computer and communications security. New York, NY, USA, pp. 199–212.

[28]    Secunia. 2007. Xen multiple vulnerabilities – advisories. Secunia security. http://secunia.com/advisories/26986/

[29]    Scholl, M. et al. 2008. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. National Institute of Standards and Technology.

[30]    Soghoian, C. 2011. How Dropbox sacrifices user privacy for cost savings. Slight paranoia: http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.html

[31]    Soghoian, C. 2011. In the matter of Dropbox, Inc. Request for investigation and complaint for injunctive relief. FTC Complaint.

[32]     Wojtczuk, R. 2008. Subverting the Xen hypervisor. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167.5640&rep=rep1&type=pdf

 

 

 

Wednesday
Jan052011

Quick authentication using mobile devices and QR Codes

Isaac Potoczny-Jones

Introduction

In this blog post, we propose an authentication scheme using QR codes and Internet-connected smart phones to allow a user to quickly sign into a web site without having to memorize or type in a username and password. The user only has to prove that they are in possession of their mobile phone. We've developed a demonstration app and web site for this approach which you can try if you have an Android smartphone. Or you can watch the video demonstration. We have also started work on a draft REST protocol, and welcome feedback.

This work is preliminary, so we are very interested in feedback on the concept and prototype.

In general, authentication can be done using multiple “factors”. The more factors that are used, the more confidence a web site can have that they have truly identified the user:

  • something a user knows, such as a password
  • something the user has, such as a smart-card or cryptographic key
  • something the user is, such as the user's fingerprint
  • the user's location
  • and probably many more

Many web sites currently use a single factor: a password. Our scheme can use a mobile phone as a second factor, or as a single factor: something the user has. In fact using a mobile phone as a single factor may be more convenient for the user and in some cases more secure than a password. One distinguishing feature of this approach is that it is not only a second factor but also a second channel. Unlike systems like Google Auth, the user does not input their second credential through their computer, but rather directly through the phone's network connection.

About QR Codes

QR codes are two dimensional bar codes that can contain a significant amount of information such as a shared key or session cookie. As in the following photograph, it is possible to disp lay a QR code on a computer screen and to scan that code with a mobile phone. This is an extremely common thing for Android users to do when they want to download apps that they have discovered on their computers. We utilize this capability to securely share secret information between the web site and the user.

User experience

In this scheme, there is a single step for both account creation and for subsequent log-in: The user scans a QR code. Edit: We have revised this workflow significantly. Please see the draft of the REST-based protocol.

Account creation: When a user visits a web site for the first time, the site generates and displays a QR code for login, and the user scans it. An account is created for them. They have no need to generate and record a username or password or any other information.

Log in: When a user subsequently visits a web site and needs to log in, the site displays a QR code that the user scans with the same mobile phone. The user is logged in without having to remember a username or password, or even remember whether they have visited that web site before.

The user can choose to increase security by locking their phone and encrypting its data. Since the web site and the phone can exchange complex data, a strong password can be generated and stored without the user having to memorize it.

In the following sections, we expand on this exchange by detailing the workflow, what is stored by each party, what attacks are mitigated, and what attacks are not mitigated.

Account creation workflow

  1. The user visits a web site on their computer for the first time.
  2. The web site generates and displays an Authentication Code (AC), which is a QR code.
    • The web site must generate a new session cookie to prevent against session fixation attacks.
    • The AC encodes the web site URL and a random secret. This will be the shared secret. (EDIT: There are trade-offs for this to become the shared secret, and that increases the trust in the QR code and the user's computer. In some circumstances, it may be better to have the app generate the shared secret.)
    • The random secret is tied to the session cookie stored in the computer's browser.
  3. The user scans the Authentication Code with the Animate Login App” (ALApp).
  4. The ALApp decodes the AC and looks up the web site in the ALApp password table.
  5. Since the web site is not in the ALApp password table, the ALApp creates a new entry and stores the random secret.(EDIT: Instead the App should generate a new random secret. This will become the shared secret.)
  6. The ALApp also generates a random user identifier, or chooses a preferred username.
  7. The ALApp uses the mobile phone's Internet connection to transmit the shared secret, the random secret, the session cookie, and the user identifier to the web site.
  8. The web site verifies that the session cookie corresponds to the random secret. This random secret can only be used to authenticate this session cookie.
  9. The web site creates an account for the user and adds the user identifier, along with the random secret to its user database.
  10. The web site marks the session cookie as authenticated and redirects the browser into the authenticated portion of the web site.

User login workflow

  1. The user visits a web site on their computer.

  2. The web site generates and displays an Authentication Code (AC), session cookie, and random secret as above. (EDIT: Using both the session cookie and random secret is unnecessary. We have clarified this in the protocol draft.)

  3. The user scans the Authorization Code with the Animate Login App (ALApp).

  4. The ALApp decodes the AC and looks up the web site in its password table.

  5. Since the web site already has an entry in ALApp password table, the ALApp looks up the shared secret and the user identifier.

  6. The ALApp uses the mobile phone's Internet connection to transmit the random secret, the shared secret, and the user identifier to the web site.

  7. The web site looks up the user identifier and verifies the shared secret.

  8. The web site verifies that the session cookie corresponds to the random secret. This random secret can only be used to authenticate this session cookie.

  9. The web site marks the session cookie as authenticated and redirects the browser into the authenticated portion of the web site.

Message format notes

  • Since no one has to memorize the shared secret, it can be long and complex, protecting against brute-force attacks and simple guessing.
  • The shared secret can be generated by the web site, and so follow that site's password complexity policy. However, if it's included in the QR code, then the code is much more sensitive.
  • If the user's phone does not have a signal for an Internet connection, the user has a backup option of having the ALApp display the shared secret so the user can type it in.
  • All messages must use HTTPS to authenticate the web site to the user and the smart phone.
  • User identifiers can be random numbers and can be generated by the user or by the web site. Alternately, the user might set a preference on the ALApp for their favorite usernames, and the ALApp can negotiate with the web site to choose a username.
  • User identifiers can be an email address.
  • During account creation, the ALApp can be instructed to share or not share information with the web site depending on user preferences. For instance, the ALApp can share the user's email address, real name, photo, etc. On the other hand, the ALApp could only share a randomly generated username that can't be tied to user names on other web sites. Of course, some sites might require more information, and if so the user might decline to create an account on that web site.

Improving security with another factor

This scheme is most interesting (to us) as a single factor authentication for web sites which currently only use username and password combinations. This scheme makes logging into such sites quick and easy. However, this scheme can be used as a single factor or as a part of a multi-factor login. There are a variety of ways to add the second factor:

  • The web site can maintain a username and password as before. The web site can enforce multi-factor authentication this way.
  • The user can keep their phone locked, requiring a login password, unlock pattern (as on Android), or other method to unlock the phone. In this case, the user is accountable for deciding whether to use a second factor.
  • Similarly, the user can store all of the shared secrets encrypted on their phone. They will need a master password to encrypt and decrypt these secrets, so the login process will be slightly slower, but they will still only have to memorize a single password. (EDIT: The newest version of the code in the git repository implements this.)
  • Alternately, the user can choose which shared secrets they value most highly, and only encrypt those passwords, allowing them to log in to low-value web sites quickly, and higher-value web sites only by decrypting those passwords.

Attacks mitigated & other benefits

  • Since the shared secret (the password) does not have to be memorized, or even typed in by a human, it can be long and complex. This mitigates against brute-force password crackers like John the Ripper (Peslyak, 2010) and Cain and Abel (Montoro, n.d.) both on the user's side and on the web site's side. This would prevent against attacks such as those used to crack so many users' passwords in the Gawker password database spill described in (Kennedy, 2010).
  • Since the user does not type their password into the computer, a virus-installed keylogger or shoulder-surfer cannot capture their password.
  • Similarly, the user can use an untrusted computer (such as one in an Internet cafe or hotel) without revealing their password.
  • A phishing web site cannot capture the user password by tricking them into typing it in. The phone sends the shared secret, and will only send it to the web site in its database.
  • Since the password is randomly generated, the user will not re-use passwords on different web sites, so a password crack on one web site will not lead to escalation of privileges on another, again as happened in the Gawker password database spill (Pompeo, 2010).
  • If the user chooses to use a randomly generated username, the user's account on one web site cannot be associated with the user's account on another web site, again as happened in the Gawker password database spill.
  • Users have more privacy options since it is easier to generate and recall random passwords.
  • The user will not lose access to a web site because they cannot remember a password.
  • Since the authentication code is sent encrypted, and the web site authenticates itself to the user via HTTPS, the random secret can't be intercepted to authenticate another user's session.
  • In several respects, this approach is similar to a browser storing passwords on behalf of a user. The major advantage this approach has is that one can easily move identities between machines.
  • Finally, the login process is quicker and easier than typing a username and password.

Vulnerabilities

  • This scheme does not prevent man-in-the-middle attacks; these need to be mitigated by HTTPS.
  • Edit: A vulnerability pointed out by Michael Tschannen is a variant of session fixation that requires a phishing attack. An attacker generates an AC for a target site and therefore knows the session cookie. The attacker tricks a user into visiting a less-trusted site and trying to log into that site. The attacker puts the AC for the target site into the (fake) less-trusted site. The user scans the AC, authenticating the attacker to the target site. This can be mitigated in two ways: 1) require that the user select the site they are logging into on the ALApp, or 2) confirm with the user the site they are logging into before sending the shared secret.
  • If the phone is lost or damaged, the user cannot access their web sites. This can be mitigated by storing the user's email address for password reset or authorizing a new phone. Another option is to encrypt the phone's password database and store it in the cloud or otherwise backing it up.
  • If the phone is stolen, the attacker can impersonate the user; therefore it is most likely desirable to encrypt the shared secrets on the phone and to authenticate the user to the phone with a single password, as above. This may not be necessary for web sites that are of low value to the user.
  • If the phone is stolen, it may be desirable to issue a revocation of all related passwords at once, rather than individually logging into different web sites.
  • When using an untrusted computer (one with a virus or in a hotel lobby), the user's account is still vulnerable as long as the session is active.
  • Many of these vulnerabilities are equivalent to any system which stores a user's passwords on their phone.

Related authentication systems

  • The ALApp can be integrated with an InfoCard / CardSpace client on the phone.
  • As with any authentication mechanism, this can be used to authenticate to an OpenID provider.
  • The workflow can be modified to use a Public Key Infrastructure instead of shared secrets. This might allow smoother revocation by issuing a revocation certificate if the phone is stolen.

Demonstration system notes

We have implemented a demonstration system which you can try out to experiment with this method of logging in. It has a number of limitations, the most obvious of which is that it can only be used to log into the demonstration web site; it will only remember one username and password. We implemented the web site login by creating a Drupal module in the hopes that it will eventually be possible to allow this type of login by installing the module. Not all of the features discussed in this paper are in the current module version. Our plan is to release the module and the app open source.

One attractive feature of this scheme is that web sites don't have to move away from using cookies, usernames, and passwords so their back-end functionality does not have to change, only the login process.

Zebra Crossing (ZXing) is a QR-code reader on Android that can easily be integrated with other apps such as ALApp.

OI Safe is an encrypted password store on Android that has an API allowing other authorized apps, such as the ALApp, to store and retrieve passwords (Potoczny-Jones, 2009).

Related work

There is a lot of work in using mobile phones as a factor in authentication. Google web applications can be configured to use a second factor, either an app installed on a phone, or a text message sent to a phone (Feigenbaum, 2010). In each case, the user is presented with a code that they type into the web site. Our proposed scheme does not require the user to type anything into the web site. It also uses a separate channel, and so mitigates "man in the browser" attacks to some extent.

Liao & Lee (2010) propose a QR-code authentication system for generating one-time passwords. Their system is more complex since it provides for mutual authentication (we use HTTPS) and yet still requires some secure channel between the web site and the mobile app.

Safelayer describes a similar authentication system using asymmetric encryption (Safelayer, n.d.). However, this is described as a multi-factor system, and requires web sites to modify their back-end systems to use public/private keypairs. Our proposed system still uses simple username / password combinations.

A system for authenticating transactions on untrusted terminals using QR codes is described in (Starnberger, Froihofer, and Goeschka, 2009) but also uses PKI and requires the user to enter a code into the computer after the smart phone performs a computation.

Conclusion

We are seeking feedback on this approach. If you see any security issues, please inform us. EDIT: We have received a lot of good feedback. There was a good discussion on Reddit's netsec that was mostly positive.

We have outlined a scheme whereby a mobile phone can be used as an authentication mechanism using QR codes. This scheme could allow users to log into a web site using a single step: scanning a QR code from their mobile phones. Alternately, this scheme can be used as one factor in multi-factor authentication.

QR codes, mutli-factor authentication, and Internet-connected smart-phones are “in the air” and others have likely come up with similar schemes. We have written this paper because we haven't found any other description of such a system, nor seen one in the wild. Mostly, we would like to use such a system since it would improve security and convenience on the Internet, so please implement this and release it open source, or help us to do so :-)

References

Feigenbaum, E. (2010). A more secure cloud for millions of Google Apps users. Official Google enterprise blog. Retrieved from http://googleenterprise.blogspot.com/2010/09/more-secure-cloud-for-millions-of.html

Kennedy, D. (2010). The real lessons of Gawker's security mess, The Firewall. Forbes. Retrieved from http://blogs.forbes.com/firewall/2010/12/13/the-lessons-of-gawkers-security-mess/

Liao, K., & Lee, W. (2010). A Novel User Authentication Scheme Based on QR-Code . Journal of networks, vol. 5, no. 8. Retrieved from http://www.academypublisher.com/ojs/index.php/jnw/article/viewFile/0508937941/2055

Montoro, M. (n.d.). Cain & Abel user manual. Retrieved from http://www.oxid.it/ca_um/

Peslyak, A. (2010). John the Ripper user manual. Retrieved from http://www.openwall.com/john/doc/CREDITS.shtml

Pompeo, J. (2010). Leaked Gawker passwords cause trouble on GMail, Twitter [web log post]. Retrieved from http://news.yahoo.com/s/yblog_thecutline/20101213/bs_yblog_thecutline/leaked-gawker-passwords-cause-problems-on-twitter-gmail

Potoczny-Jones, I. (2009). CryptoIntents, A discussion of the cryptography and keystore intents in OI Safe. Retrieved from https://code.google.com/p/openintents/wiki/CryptoIntents

Safelayer. (n.d.) QR-Scan OTP: ergonomic authentication. Retrieved from http://sandbox.safelayer.com/index.php?option=com_content&view=article&id=466%3Aqr-scan-otp-ergonomic-authentication&catid=1%3Asemantic-web-trust-portal&Itemid=2&lang=en

Starnberger G., Froihofer L., and Goeschka, K. M. (2009) . QR-TAN: Secure Mobile Transaction Authentication . IEEE Computer Society. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.149.2315&rep=rep1&type=pdf

Friday
Oct152010

Monitoring Distributed Real-Time Systems: A Survey and Future Directions

Monitoring Distributed Real-Time Systems: A Survey and Future DirectionsAlwyn Goodloe (NIA) and Lee Pike (Galois, Inc), NASA Langley Research Center, 2010.

Runtime monitors have been proposed as a means to increase the reliability of safety-critical systems. In particular, we explore runtime monitors for distributed hard real-time systems, such as fault-tolerant data buses and control systems for avionics and spacecraft. This class of systems has had little attention from the monitoring community. We motivate the need for monitors by discussing examples of avionic systems failure. We then describe work in the field of runtime monitoring. We present potential monitoring architectures for distributed real-time systems, and then we discuss how those architectures might be used to monitor properties of real-time distributed systems.

Click to read more ...

Wednesday
Oct062010

Schrödinger's CRCs (Fast Abstract)

Dr. Lee Pike's short abstract revisiting fault-tolerance of cyclic redundancy checks (CRCs), expanding on the work of Driscoll et al.. It introduces the concepts of Schrödinger-Hamming weight and Schördinger-Hamming distance, and argues that under a fault model in which stuck-at-one-half or slightly-out-of-spec faults dominate, current methods for computing the fault detection of CRCs may be over-optimistic.

Click to read more ...

Thursday
Aug122010

White Paper: High Assurance Software Development

Galois is pleased to announce a new white paper entitled High Assurance Software Development, written by David Burke, Joe Hurd and Aaron Tomb.

The purpose of this paper is describe how to make software assurance a part of a science of security. Software assurance as practiced is a grab-bag of techniques, heuristics, and lessons learned from earlier failures. Given the importance of software to critical infrastructures (electricity, banking, medicine), this is an untenable situation; the smooth functioning of our society depends on this software, and we need a more rigorous foundation for assessments about the trustworthiness of these systems.

In this paper we present an evidence-based approach to high assurance, in which diverse development teams can communicate in a common language to tackle the challenges of developing secure systems. Furthermore, this framework supports formal inference techniques (in particular, a trust relationship analysis), so that we can use automated reasoning to deal with scalability issues. Perhaps most importantly, an evidence-based approach lets us tailor the tools that we bring to bear on each claim: formal methods: testing; configuration management; and so forth all have their place in an assurance argument. In the end, it's all about deploying systems where the residual risk has been minimized, given finite resources and time. Understanding this and managing it effectively is what the science of security is all about.

Click to read more ...