The post Webinar: Catch Up with FIDO Plus Open AMA Session appeared first on FIDO Alliance.

Besides generic session authentication, there is an increasing need to gather explicit user consent for a specific action, i.e. “Transaction Confirmation”. Transaction Confirmation allows a relying party to not only determine if a user is involved in a transaction, but also confirm that the transaction is what the user actually intended – for example, whether they intended to pay $1000 to company X for purchasing product Y, or whether they consent to have specific data shared with another party, such as test results with a doctor.

This paper provides an overview on Transaction Confirmation and the drivers for its support including: regulatory requirements (PSD2, eIDAS); addressing friendly and mobile fraud; and to enable online binding agreements. It explains current approaches for Transaction Confirmation, including through FIDO protocols for native applications, and the value of adding support for it directly in web browsers. It concludes with a call for feedback from relying parties on whether they would like to see Transaction Confirmation should be supported directly in web browsers.

The post White Paper: FIDO Transaction Confirmation appeared first on FIDO Alliance.

Support for FIDO in browsers and operating systems is widespread and growing fast. Enterprises now have better tools to replace easily compromised passwords with simpler, stronger FIDO Authentication and eliminate phishing, man-in-the-middle and other security attacks. But, if you want to deploy FIDO in your enterprise, what are the first steps? Do you need to explain “why FIDO?” to your CISO? What do the timelines look like? Should you build your own server or work with a vendor? What FIDO authenticators should you accept? How do you manage  them? 

The FIDO Alliance Enterprise Deployment Working Group (EDWG) will answer these questions, and more, in its new white paper series. The series aims to educate corporate management and IT security on the improvements available for authentication today and how to leverage them within their own organizations. This work is dedicated to eliminating passwords and securing the simple act of logging into company systems and applications. 

First up in the series is the primer “CXO Explanation: Why Use FIDO for Passwordless Employee Logins?” This document is the guide for you and/or the executive leaders in your organization as to why you should invest in FIDO2 deployment for your employees.

It addresses all of the common questions from CXOs on the value proposition of FIDO Authentication and how the FIDO2 passwordless framework addresses the authentication needs and challenges of companies for the modern workforce. Read it now at https://fidoalliance.org/white-paper-cxo-explanation-why-use-fido-for-passwordless-employee-logins/ and pass it along to colleagues.

Subsequent entries in this educational series will focus on server deployment, authenticator choices, authenticator life-cycle management, and credential acceptance in the enterprise. This series is part of the Alliance’s strategy to provide expert deployment guidance to our community in order to support the rapidly growing number of FIDO implementations across a variety of use cases. Please watch this space as we publish more in this Enterprise Series over the coming months. 

The post New White Paper Series Provides How-tos and Best Practices for Going Passwordless in the Enterprise appeared first on FIDO Alliance.

Editor’s note: For the background information on the 2020 Hackathon in Korea, see the April blog post: “2020 FIDO Hackathon: Goodbye Password Challenge in Korea.”  To learn more about examples of proposed development ideas, please read the June blog post: “2020 FIDO Hackathon in Korea: Learn & Implement Phase.”

In the afternoon of July 1st, 2020, a Mid-Term Meetup Event for FIDO Hackathon – Goodbye Password Challenge was held at Telecommunication Technology Association (TTA). Originally, the Hackathon Steering Committee had planned a full-day onsite final implementation and evaluation day, followed by a month and a half online training phase.  Due to the global pandemic, we had to change our schedules in accordance with school calendar disruptions and summer holidays. We decided to have a half-day mid-term meetup event for participants. This allowed us to help the teams to stay on course while providing a safe environment for people to learn from each other face-to-face.

Nineteen different teams participated in the event, half of them face-to-face with strict public health guidance applied, and the other half virtually. The meeting gave opportunities for teams to share their FIDO protocol-based online service development ideas and current development status, learn from each other and receive valuable feedback from FIDO Alliance Korea Working Group members.

In addition to sharing their projects’ current development status, the teams had the opportunity to present the “homework” they have completed after online training.  The homework was writing a simple article on the web, with answers to the following questions:

• What is FIDO Alliance?
• What are the FIDO protocols?
• What are the benefits of implementing FIDO protocols?
• (Option) What services/products are you developing for the 2020 FIDO Hackathon and what would be the value of adopting FIDO protocols for online authentication?

We were very pleased with the articles we received. You can read examples (mostly in Korean) by visiting these following links:

• No matter how passwords are complicated, they are not safe!  Learn FIDO concepts
• FIDO Authentication: Good security knowledge to learn while you are quarantined at home
• 2020 FIDO Hackathon Homework – My Plan to Develop FIDO Based IoT Solution for Home
• FIDO – New technology standard to solve problems with IDs and Passwords 
• Let’s learn about FIDO Alliance and FIDO Specs
• Summary on FIDO Alliance and FIDO Specs

We hope this short blog gives you a better understanding of the current status of the 2020 FIDO Hackathon in Korea.  We will be back soon with more updates after the final evaluation — scheduled for this week. 

The post 2020 FIDO Hackathon in Korea Update: Mid-term Meetup Event appeared first on FIDO Alliance.

The post Webinar: PSD2 Support: Why Change to FIDO appeared first on FIDO Alliance.

The post Webinar: FIDO & eIDAS: Providing Secure and Seamless Electronic Services in the EU appeared first on FIDO Alliance.

The post Webinar: FIDO & eIDAS: Providing Secure and Seamless Electronic Services in the EU appeared first on FIDO Alliance.

Megan Shamas, Director of Marketing, FIDO Alliance

Over the last several years, eIDAS regulation has been widely adopted by the EU member states, and several eIDAS-compliant services and eID schemes have been rolled out across Europe.

eIDAS stands for “electronic identification, authentication and trust services.” It builds the legal basis for cross-border interoperability of electronic identification, authentication, and electronic signatures amongst EU Member States. eIDAS is meant to enable mutual recognition of eID and trust services across the EU in a regulated, secure and private manner. In a world where transactions are increasingly digital and without borders, this recognition and trust is essential.

FIDO Authentication is a natural fit for the delivery of services that meet eIDAS regulations, and many of our members are working with governments and service providers to enable secure and seamless electronic interactions throughout the EU. To give an overview and more in-depth details on how FIDO and eIDAS intersect, we’ve released two new white papers. The first, “Introduction of FIDO and eIDAS Services” serves as an introductory white paper describing the relationship between FIDO2 standards and eIDAS compliant schemes that can accommodate modern authentication protocols. The second, “Using FIDO with eIDAS Services” is a more detailed look at how FIDO can be used with eIDAS services, including architectural concepts for integration of FIDO2 into the eIDAS interoperability framework.

Sebastian Elfors, Solutions Architect at Yubico, the lead contributor for the new papers, had this to say about the intersection of FIDO and eIDAS:

“The modern FIDO standard, and its wide adoption by the largest IT-companies all over the globe, provides a viable framework for expanding and modernizing eIDAS services across Europe. In the intersection between eIDAS and FIDO, there are a number of emerging deployment scenarios that will benefit the public sector in the European Union. There are already several eID schemes being notified by the EU Commission this year, the number of Qualified Trust Service Providers are constantly growing, and more government services are enabling cross-border eID support.”

To expand on this topic and information in the new white papers, Sebastian will join our executive director and CMO Andrew Shikiar to lead a webinar on May 28 at 15:00 CEST. The webinar will include:

• An introduction to eIDAS
• An overview on how to use FIDO as part of an eID scheme
• An overview on using FIDO2 for authentication to Qualified Trust Service Providers (QTSPs)

There will be time for Q&A, so please bring your questions! 

Register for the eIDAS webinar here.

Speakers: Sebastian Elfors, Senior Solutions Architect, Yubico and Andrew Shikiar, Executive Director and CMO, FIDO Alliance

Download the Introduction to FIDO & eIDAS Services white paper here.

For details, including architectural concepts for integration of FIDO2 into the eIDAS interoperability framework, please read the complementary white paper, “Using FIDO with eIDAS Services.”

The post FIDO & eIDAS: Providing Secure and Seamless Electronic Services in the EU appeared first on FIDO Alliance.

Editor’s Note: We began the Hackathon program last year to support the local developer community and drive market adoption of FIDO Authentication standards in Korea. The 2019 FIDO Hackathon was a hybrid of a three-month-long mentorship and a service development competition, which unlocked the potential of FIDO protocols along with unexpected positive outcomes. Please visit the following blog postings to learn more about 2019 FIDO Hackathon:

FIDO Authentication Developer Support Program: FIDO Hackathon in Korea
FIDO Hackathon in Korea: A Q&A with the Top 3 Winners and their Mentors
FIDO Hackathon in Korea: Meet the Finalists

The FIDO Alliance Korea Working Group is thrilled to announce the opening of  online registration for the 2020 FIDO Hackathon – Goodbye Password Challenge in Korea. 

The program can be simply summarized as following three phases:

LEARN – Learn how to adopt FIDO protocols
IMPLEMENT – Implement FIDO protocols into participants’ online services
CHANGE – Change to simpler and stronger FIDO authentication

Now, let us walk through the three simple phases.

Once the registration closes at the end of April, those who qualify will be invited to the online learning stage created by the FIDO Alliance Korea Working Group Technical Sub-Group. Toward the end of the LEARN phase, participating teams will be given a very easy online assignment. Those who score in the  top 20 will be invited to the next stage. The LEARN phase is scheduled to be completed by the end of June.

The IMPLEMENT phase will take place in July, inviting the top 20 teams to one-day, in-person events. Participants will fine-tune their service developments in the morning with hands-on support by FIDO experts from FIDO Alliance members. In the afternoon and evening (if necessary), participants will  go through onsite evaluation. In case there is still a concern for public health in summer, we have prepared various backup plans, including completely converting the event into multiple online evaluation sessions over a period of time.

At the annual multi-day FIDO Seoul Public Seminar in early September, the top 5 teams will show how they have made the CHANGE to simpler and stronger FIDO Authentication, followed by award ceremonies. The top five teams and finalists will receive trophies and certification of completion, and over KRW20,000,000 worth of gifts and prizes.

Dr. Daniel Ahn, the Co-Chair of FIDO Alliance Korea Working Group would like to welcome local developers to join the 2020 FIDO Hackathon with following remarks:

“Due to the recent global public health concerns, the needs for simpler and stronger FIDO authentication will be increased due to the increasing demands for ‘untact’ and remote working technologies. Building upon the success of 2019 FIDO Hackathon in Korea, the FIDO Alliance Korea Working Group members will diligently prepare yet another meaningful event for local developers.”

On behalf of all the sponsors of 2020 FIDO Hackathon, Mr. Junho Shin, the Co-Leader of FIDO Alliance Korea Working Group Public Policy and Certification Sub-Group, would like to share a few words:

“Without knowing what would happen early this year, we began preparing 2020 FIDO Hackathon to be as much virtual as possible, for possible global-scale program expansion in upcoming years. Therefore, we are technically and operationally fully prepared to run this event without any public health concern, so those who consider joining the program would not lose the priceless opportunity to showcase their talents to the world.”

We thank you for your continued interest and support for FIDO Hackathon – The Developer Support Program and welcome you to visit our official registration site by clicking the 2020 FIDO Hackathon banner below:

More resources on the event:
Click here to download the RFP (Request for Participation).
Click here to watch YouTube contents (e.g. Intro, Welcome Remarks, FIDO Spec Updates, How to Join)

Special thanks to following sponsors:
Signature Sponsor: Ministry of Science and ICT | Telecommunication Technology Association
Gold Sponsor: Samsung Electronics, BC Card, eWBM, AirCuve, Octaco, CrossCert, PSEF

The post 2020 FIDO Hackathon: Goodbye Password Challenge in Korea appeared first on FIDO Alliance.

Last week the FIDO Alliance held an impactful policy forum in D.C. with partners Better Identity Coalition, Identity Theft Resource Center (ITRC) and National Cybersecurity Alliance. This is the fourth year that we’ve held this event, which aims to provide attendees with a broadened view of the intersection of identity, authentication and policy.

The talks from government officials showed that agencies are in tune with the need, and society’s demand, to provide more seamless digital services to citizens while increasing security. Grant Schneider, the federal government’s chief information security officer, summed it up: “Our goals from an identity standpoint is first and foremost, how do we increase security that also increases usability? Because we have to do both at the same time.”

The good news is that government officials recognize the availability of modern authentication technology and how it can help them achieve their goals. The Social Security Administration’s CIO Rajive Mathur, spoke about plans to digitize SSA, including rolling out FIDO-based logins in the near future. One federation partner they are considering is login.gov, which uses FIDO Authentication today. “Our goal is to eliminate passwords,” Mathur said.

Several speakers pointed out that identity is first a societal issue, rather than just a technology or policy issue. This was clear in the fireside chat with identity-theft victim Axton Betz-Hamilton, who shared her case and talked about the emotional toll it had on her, and the difficult recovery process. Betz-Hamilton is just one of millions of people who are impacted by identity theft each year, and endure its deep and lasting ramifications.

Another impactful talk on the societal impacts of identity was from Reverend Ben Roberts from the Foundry United Methodist Church in D.C. Rev. Roberts talked about the church’s ID Ministry, which assists poor, homeless or others lacking in resources to acquire government identification. His talk was a reminder about how much one’s identity is based on having basic documentation such as birth certificates, social security cards and state-issued IDs — and how verifying identity is critical to receiving societal staples such as employment, housing and/or government assistance.

“For those of you building systems of identity and authentication, be intentional, be mindful,” Rev. Roberts said in his talk. He’s absolutely right. As we look at identity and providing best practices around remote identity verification processes and technologies, we need to be aware there are people without access to basic identity documentation and ensure that this large population of people isn’t left behind.

If you missed our policy day, you can still watch the talks — the webcast is archived on YouTube at https://youtu.be/2MxHT8o3lfY.

The post 2019 Policy Forum Sheds Light on Societal Impacts of Identity & Authentication appeared first on FIDO Alliance.

Stay tuned for more developer content here on the blog (including updates on the Korea Hackathon) and on our Developer Resource webpage. 

By Henry Lee and Sanghun Won, Co-Chairs, FIDO Alliance Korea Working Group

During the FIDO seminar in Seoul last December, the FIDO Alliance Korea Working Group announced its intentions to help make 2019 the year of FIDO deployment. In addition to helping our members with their own FIDO projects, we agreed that engaging local developers would be a key component to success. We studied various ways to support local developers, including college students and entrepreneurs, and decided that running a Hackathon would be the best avenue to reach this community.

We named it a Hackathon for easier communication of what we’re trying to accomplish, but the program is unique in that it is a hybrid of a venture-type acceleration program and a new service development competition. We structured the FIDO Hackathon in four different blocks (see Diagram 1).

After the successful launching event, we received about 40 proposals and chose 25 of them to participate in onsite presentation evaluations.

We are currently at the “develop” stage of our Hackathon, where 13 different teams who passed the presentation evaluations are diligently developing their own unique FIDO-enabled services through three-month mentorship programs (see Table 1).

Over 50 college students and entrepreneurs from 20 different organizations are participating in these mentorship programs, with development ideas covering online security, IoT, drones, retail kiosks, FinTech and blockchain. The participating FIDO members are inspired by these innovative ideas and thankful for the tremendous amount of positive energy these young minds bring to the field.

At the beginning of this process, we set four ground rules for all stakeholders: respect, compete, learn and collaborate. These rules have been well implemented and reflected throughout the program. For example, we plan and are excited to have a mentor and mentee party soon. This will be a great venue for mentees and assigned mentors to all get together under a single roof and share their activities and learn from each other.

We want to give a huge thanks to those who are actively involved in these efforts, especially to those mentors from 10 different member companies. We look forward to sharing more exciting stories and awarding our Hackathon winners at the FIDO Alliance member plenary in Seoul this September. Watch for a follow-up blog, where we tell you all about our winners!

The post FIDO Authentication Developer Support Program: FIDO Hackathon in Korea appeared first on FIDO Alliance.

At the FIDO Alliance, we have a focused set of activities to achieve our mission. We do three things: develop specifications, operate certification programs, and run programs to assist with the market adoption of FIDO Authentication.

Of these three, certification is really what makes the FIDO ecosystem tick. A core tenet of FIDO Authentication is interoperability, i.e. ensuring that everything FIDO – devices, servers, services – work together for an easy and secure authentication experience. Our certification program provides the necessary validation that products do conform to the FIDO specifications and do indeed work with other implementations.

Service providers understand the value of FIDO certification. This is why we’re increasingly seeing service providers list FIDO certification as a requirement on RFPs, and why they tell us they look for the FIDO Certified logo when evaluating vendors for new FIDO rollouts. Only companies that have achieved certification can use the FIDO Certified logo in their marketing materials – product sheets, packaging, brochures and websites. If you’re certified — use it!

Technology providers also understand that FIDO certification is a differentiator that puts them at a sales advantage. The enthusiasm around and growth of FIDO Certified ecosystem of products attests to this. We’re excited to announce our newest certifications today, which puts us over 630 certified products. FIDO2 and FIDO UAF certifications were strong this quarter, as tech providers look to provide solutions for those with cross-platform and mobile-first strategies, respectively.

We also recently awarded our second Biometric Component Certification to Cirrus Logic (the first was Samsung), and the fifth Universal Server in the world to NRI SecureTechnologies,Ltd. Universal Servers are great, because they support the full range of FIDO Authenticators (FIDO UAF, FIDO U2F, FIDO2). We always recommend that relying parties consider deploying a Universal Server in order to ensure optimal end-user experience and compatibility.

These companies have achieved FIDO certification since our last quarterly update:

• FIDO2: Bank of America; Ensurity Technologies Private Limited; FUJITSU LIMITED; GOTRUSTID Inc; International Systems Research Co.; KONA I Co., Ltd; LoginID; NEC Corporation; Octatco; Secret Double Octopus; SGA Solutions; SupremaID; Synaptics Incorporated, WhoAreYou Holdings Ltd.
• Universal Server: NRI SecureTechnologies, Ltd
• FIDO UAF: Adnovum SG; Aisino; Beijing YangFanWeiYe Security Technology Co. Ltd; Movenda SPA; NEC Corporation; Penril Datability; WebComm Technology Co., Ltd
• Biometric Component: Cirrus Logic

In other Biometric Component Certification program news, Idiap Research Institute, ELITT/Leti CEA and Beijing Unionpay Card Technology Co., Ltd have joined iBETA as accredited independent labs performing biometric evaluations (see our labs page for the details).

Technology providers interested in getting started with FIDO certification should start with the Certification Overview. Ready for interoperability testing? Join us at our next event, September 9-11 in Lisbon Portugal, where we will be testing FIDO UAF, FIDO U2F and FIDO2 implementations. Get all of the details and register here.

The post Quarterly Certification Update: Making the FIDO Ecosystem Tick appeared first on FIDO Alliance.

The post White Paper: FIDO UAF and PKI in Asia – Case Study and Recommendations appeared first on FIDO Alliance.

FIDO specifications are part of a community of interlinking specifications. FIDO Authentication depends on specifications from the World Wide Web Consortium (W3C), Internet Engineering Task Force (IETF) and others to define how secure authentication should work. We are excited to announce that one of the specifications that the FIDO Alliance has long been anticipating has made a very important step forward: the IETF Token Binding specification has been sent to the IETF editor, which means that it is one step away from being published as a final standard.

Token Binding has been included in the FIDO specifications as an important security measure. Token Binding cryptographically ties a token to a host, ensuring that the server knows that it’s talking to the right browser. Some of the uses for this are to ensure that cookies can’t be stolen, sessions can’t be hijacked and OAuth bearer tokens can’t be repurposed.

One of the most important security aspects of FIDO specifications is their cryptographic assertion of the origin: the protocol, server DNS, and port that describe the server that is requesting authentication – for example, “https://fidoalliance.org.” FIDO authenticators sign over the origin with an associated private key – this is how the FIDO Alliance accomplishes its anti-phishing mission. Token Binding is part of the protections of the origin because it ensures that the origin can’t be spoofed. For example, even if an attacker were to hijack a DNS server, redirect all traffic to “fidoalliance.org” to their own nefarious servers, and authenticate to clients as “fidoalliance.org” (assuming they also somehow obtained a valid TLS certificate for that domain), the Token Binding protocol would detect this “man-in-the-middle” between the client and the real “fidoalliance.org.”

Although Token Binding is important to the FIDO specifications, it has been optional so far – mostly because the specification wasn’t complete and adoption is still picking up. The completion of the Token Binding specification is an exciting opportunity for its adoption. Seeing Edge and Chrome support Token Binding is an important step to seeing broad ecosystem adoption of this new security standard.

We look forward to seeing more future adoption of Token Binding by other browser vendors. Similar to its inclusion as an advanced security measure in FIDO specifications, Token Binding has been included in the OpenID Connect Enhanced Authentication Profile (OIDC EAP), where Token Binding and FIDO sit side-by-side in OIDC’s vision for a future of strong authentication. Token Binding will also serve an important role in the U.S. government’s identity and authentication standards, including NIST SP 800-63-3, where it is required for verifier impersonation resistance. As with all standards, the road will be long to see adoption and implementations, but we are looking forward to the day Token Binding has enough industry adoption for it to become a mandatory part of the FIDO specifications.

FIDO TechNotes highlight aspects of the FIDO specifications that are important for practitioners to understand. TechNotes shed light on architectural choices, explain best practices, and give guidance to deployers of the technology. TechNotes are part of an on-going series featuring the technology and evolution of the FIDO Alliance.

The post FIDO TechNote: The Growing Role of Token Binding appeared first on FIDO Alliance.

Adam Powers, FIDO Alliance Technical Director

There is a frequently mentioned but little understood term in FIDO: attestation. Even engineers implementing FIDO products are often confused with how attestation works or why it is needed. This Tech Note is an attempt to clarify attestation and its role in FIDO transactions; the post is largely for the technical community, but hopefully it is clear enough to the lay-person with a basic understanding of FIDO as well.

To start with, every time a user registers with a new service (Google, Facebook, PayPal, GitHub, etc.) the FIDO authenticator generates a new key pair for that service. The keys are necessarily unique to that service and aren’t shared across services. This is the keypair most commonly associated with FIDO, and it is referred to as the “credential key pair” or just “the key pair”. When a user registers with a service a new key pair is generated, and the public key is sent to the service to be stored and used in the future to authenticate the user. That key pair is not the attestation key pair, and to confuse things further that key pair gets used for an operation called “assertion” (the signing of a challenge during authentication). The terms “assertion” and “attestation” are frequently confused – assertion occurs when authenticating; attestation occurs during registration.

Figure 1: A new “credential key pair” is generated for each service that a user registers with.

With that context in mind, what is attestation? It is a key pair that is burned into the device during manufacturing time that is specific to a device model. For example, all YubiKey 4 devices would have the same attestation certificate; or all Samsung Galaxy S8’s would have the same attestation certificate. The attestation is specific to a device model and can be used to cryptographically prove that a user has a specific model of device when they register. When a user creates the new “credential key pair” mentioned above, the public key that is sent to the service is signed with the attestation private key. The service that is creating the new account for the user can verify that the “attestation signature” on the newly created public key came from the device.

Generally speaking, attestation keys have associated attestation certificates, and those certificates chain to a root certificate that the service trusts.  This is how the service establishes its trust in the authenticator’s attestation key.

Figure 2: During registration, a new public key is created and signed by an attestation private key that was created with the device when it was manufactured.

Attestation accomplishes two things: 1) if an attacker intercepts a registration message with their own, they would not be able to swap out the new public key with their own since the attestation signature wouldn’t match; and 2) it allows the service to trust that it knows the provenance of the authenticator being used.

At first glance, it might seem like preventing an attacker from replacing the public key with their own is the more important aspect of attestation. However, registration for FIDO typically requires that a user already have an authenticated session and communications are TLS protected, so there isn’t much opportunity for malicious behavior. For this reason, many services will not reject an authenticator if it is using “self attestation”. Self attestation (also called surrogate attestation) is when an authenticator uses a self-signed certificate instead of an attestation certificate that chains back to some root certificate.

Some services though, such as those in the financial industry or the public sector, may be required to know more about the devices that are accessing their services. They must guarantee that encryption keys are secure, biometrics are of a certain level of accuracy, etc. This is where the second aspect of attestation comes in, which is enabling the service to trust that the registration request is coming from a specific model of FIDO authenticator.

During registration the unique model number of the device is sent to the service along with the newly created public key. The unique model number is an “Authenticator Attestation ID” (AAID) in UAF; an “Authenticator Attestation Globally Unique ID” (AAGUID) in FIDO2; or a “Attestation Certificate Key Identifier” in U2F. Upon receiving a new public key from a user during registration, this unique identifier can be used to look up a metadata statement in a service such as the FIDO Metadata Service (MDS). Each record in the MDS has an AAID, AAGUID or Attestation Certificate Key Identifier that corresponds to the device.

Once the right record is found, the record has two essential kinds of information: 1) an “attestation root certificate”; and 2) the metadata about the device. We previously mentioned “self (or surrogate) attestation”, but devices can also use “full basic attestation” where the attestation certificate chains up to some well-known attestation root certificate. Assuming that the attestation signature over the public key is correct and the certificate chain is validated to root certificate, a service can then trust the other metadata about the device, such as the security and biometric characteristics of the device.

(Note: the FIDO authenticator certification program tests for and ensures that keys and other secrets are protected against external threats. FIDO will soon be launching a biometric certification program that ensures biometrics correctly verify users. Both certifications show up as metadata about the authenticator, providing more information to enable services to establish stronger trust in the authenticators.)

Figure 3: During registration, a service can use a device’s unique identifier to look up the “root attestation certificate” and attributes about the device from a Metadata Service (MDS).

For UAF and U2F, each has its own attestation format. UAF has a custom “tag length value” (TLV) structure that contains more information than just the attestation signature, and the U2F protocol simply has an attestation certificate and an attestation signature. As FIDO2 and WebAuthn are rolling out, more and more platforms are including attestation as a service that is built into the platform. Android has both SafetyNet and Android key attestation. Most modern PCs have TPM attestation, and more attestation formats are expected in the future as platforms evolve. For that reason, WebAuthn defines multiple attestation formats and allows new ones to be added in the future.

Hopefully that helps clarify what attestation is and how it is used, but there is just one more point to make – and this is really the reason I am writing this article. Please note that attestation is supposed to be unique to a device model, not an individual device.

One of the key attributes of attestation, as with all FIDO operations, is that it must preserve the privacy of the user. The reason that attestation keys are common to a model of device rather than each individual device having its own keys is so that attestation can’t be used as a way of identifying and tracking users. During a recent FIDO interop, I had the pleasure of working with some incredibly smart, well-educated engineers that had fantastic implementations of FIDO; however, they didn’t understand that they shouldn’t create a new attestation certificate for every instance of a device. This is potentially problematic – if everyone buying a model of phone or security key gets the same model of the device, but has a different attestation certificate, that attestation certificate can be used to track and identify the individual across services. FIDO is founded on a principle of strong privacy, and using attestation to track users would violate FIDO’s privacy principles. Making sure that attestation certificates are used across large batches of authenticators of the same model (100,000+) ensures that users can’t be tracked based on their attestation certificate. My hope is that this blog post helps ensure that we are all using attestation certificates correctly and protecting the privacy of users.

The post FIDO TechNotes: The Truth about Attestation appeared first on FIDO Alliance.

• Launch of FIDO2: In partnership with the World Wide Web Consortium (W3C), FIDO Alliance announced the achievement of a major standards milestone in the global effort to bring simpler yet stronger web authentication to users worldwide. The FIDO2 project, designed to bring FIDO authentication to billions of users through updated web browsers and device operating systems, launched with committed browser support from Google Chrome, Microsoft Edge and Mozilla Firefox, and marks a significant step towards creating a web less reliant on passwords and making FIDO standards ubiquitous across all platforms. The FIDO Alliance enables users to securely access web services through browsers via a single gesture — such as touching a fingerprint sensor, looking at a camera or inserting a security key.
• Amazon and Facebook join FIDO Board of Directors: For consumers, both security and ease of use are paramount. As a result, FIDO seeks companies that are defining the digital economy to join its board. The latest appointments, internet giants Amazon and Facebook, join other leading global technology, financial services and e-commerce board members in driving the Alliance’s strategic vision to reduce the world’s reliance on passwords with stronger, simpler authentication
• GDPR: As detailed in a recently released white paper, FIDO standards were built with a “privacy by design” approach and are optimised for compliance with the new regulation, which came into force on May 25, 2018. With a wide range of FIDO(R) Certified products on the market, FIDO authentication represents the best way for organisations to implement stronger authentication that meets GDPR’s rigorous requirements, while at the same time, enhancing the user experience
• Payment Services Directive 2 (PSD2) and solving the strong customer authentication challenge in Europe: Concerns among the European financial ecosystem around how to best comply with PSD2 range beyond simply meeting the security requirements; the costs, the impact of GDPR and overall customer experience also are important considerations. FIDO Authentication offers financial institutions scalable, standards-based solutions to the PSD2 Strong Customer Authentication (SCA) challenge in Europe. The consortium has been working to educate the market with whitepapers, a specialist webinar and other resources on the topic
• European Working Group update: Launched in November 2017, the Group was established to help accelerate the use of FIDO authentication standards in Europe. Co-chaired by executives from Gemalto and ING, the Working Group has grown to its current composition of 22 member organisations and has helped inform FIDO’s positions on the aforementioned regulatory activities while also working to educate and engage the European marketplace

“With the recent arrival of the General Data Protection Regulation (GDPR) this week, European regulators are introducing a new era for privacy best practices that will influence the world at large,” said Brett McDowell, executive director of the FIDO Alliance. “Members of the FIDO Alliance have published this guideline as one of many activities designed to help educate businesses on the benefits of FIDO — today’s leading privacy and security best practice for strong customer authentication — easing regulatory compliance while improving the customer experience across Europe’s Digital Single Market.”

About the FIDO Alliance
The FIDO (Fast IDentity Online) Alliance, www.fidoalliance.org, was formed in July 2012 to address the lack of interoperability among strong authentication technologies, and remedy the problems users face with creating and remembering multiple usernames and passwords. The FIDO Alliance is changing the nature of authentication with standards for simpler, stronger authentication that define an open, scalable, interoperable set of mechanisms that reduce reliance on passwords. FIDO authentication is stronger, private, and easier to use when authenticating to online services.

The post FIDO ALLIANCE ACCELERATES MOMENTUM IN EUROPE IN 1H 2018 appeared first on FIDO Alliance.

When it comes to authentication in the new era of GDPR, there are three things that every organisation should know:

1. GDPR requires companies to implement data protection safeguards. Last year, 81 percent of all breaches were due to attacks that exploited weak or stolen passwords*. Strong, multi-factor authentication (MFA) is a fundamental building block of cyber security and data protection. Any approach to data protection that does not include the use of MFA is incomplete. But it’s important to remember that not all forms of MFA are created equal – older, first-generation MFA technologies are less effective now that attackers have learned how to bypass them.
2. GDPR requires firms to respond to requests from individuals to view, change, delete, or transfer their data. It also means that businesses have to demonstrate that they obtained the consent from individuals to process their data, or explicit consent if the data is of a sensitive nature. In order to fully comply with this requirement, organisations must also be able to authenticate the identity of people making these requests.
3. Biometrics are one of the most promising technologies available to deliver strong authentication, offering enhanced security and a far simpler user experience. However, GDPR highlights biometric data as a “sensitive” category of personal information requiring robust protection. Therefore, any entity implementing biometric authentication must ensure that its use of biometrics is compliant.
   

FIDO Alliance standards were created from the outset with a “privacy by design” approach and are a strong fit for GDPR compliance. Crucially, FIDO delivers authentication with no third-party involvement or tracking between accounts and services. And when it comes to biometrics, FIDO standards prevent this information from being stored and matched in servers – it never leaves the user’s device – and FIDO(R) Certified devices do not allow for any biometric data to be captured.

For more information about GDPR and how FIDO Authentication works, download our new white paper.

The post GDPR arrives in Europe – FIDO’s perspective appeared first on FIDO Alliance.

 MOUNTAIN VIEW, Calif., MAY 15, 2018 — The FIDO Alliance announced today that Facebook has been appointed to its Board of Directors. With this appointment, Facebook joins other leading global technology, financial services and e-commerce board members in driving the Alliance’s strategic vision to reduce the world’s reliance on passwords with stronger, simpler authentication.

 The FIDO Alliance develops specifications for interoperable strong authentication with compliant mobile and web applications and PC platforms. Through its use of on-device public key cryptography and convenient authenticators such as security keys and biometrics, FIDO Authentication is more secure, private and easy to use than passwords and other forms of strong authentication.

 “Weak passwords continue to cause unnecessary problems that could be avoided if strong authentication options were more widely deployed and used. We are proud to join the FIDO Alliance Board and help them in their goal to make simple, strong authentication more broadly available through web browsers and on mobile and PC platforms,” said Brad Hill, Facebook software engineer.

 While new to the Board, Facebook has played an active role in supporting the adoption of FIDO Authentication since January 2017 when they made it possible for any of their 2 billion daily users to use a FIDO-supported security key to log in.

 In addition to Facebook, many top service providers, such as Aetna, Google, PayPal, Samsung, Bank of America, NTT DOCOMO, Dropbox and Github, have made FIDO Authentication available to their broad user bases. Just last month, Google, Microsoft and Mozilla also committed to supporting the recently announced WebAuthn standard in their flagship browsers, making FIDO Authentication available to users across the web.

 “We are pleased to welcome Facebook as the newest member of our Board of Directors,” said Brett McDowell, executive director of the FIDO Alliance. “As one of the most used web and mobile services in the world, Facebook will help the FIDO Alliance take another step closer in achieving its mission of enabling truly innovative authentication experiences that delight users, while also solving the security problems that plague passwords and one-time-passcodes today.”

 Learn more about FIDO Authentication by visiting https://fidoalliance.org/about/what-is-fido/.

About FIDO Alliance
The FIDO (Fast IDentity Online) Alliance, www.fidoalliance.org, was formed in July 2012 to address the lack of interoperability among strong authentication technologies and remedy the problems users face with creating and remembering multiple usernames and passwords. The FIDO Alliance is changing the nature of authentication with standards for simpler, stronger authentication that define an open, scalable, interoperable set of mechanisms that reduce reliance on passwords. FIDO Authentication is stronger, private, and easier to use when authenticating to online services.

 Contact:
press@fidoalliance.org

The post Facebook Joins FIDO Alliance Board of Directors appeared first on FIDO Alliance.

It was a productive week at the RSA Conference 2018 where a dominating  theme centered on FIDO2 Authentication, a major standards milestone in the global move toward simpler, stronger authentication on the web. An abundance of FIDO members were in attendance exhibiting their security solutions, including those with FIDO® Certified solutions for current and planned offerings inclusive of FIDO2 Authentication.

FIDO2 Authentication has garnered support from Google Chrome, Microsoft Edge and Mozilla Firefox as we move away from the era of being dependent on passwords and into a more ubiquitous, phishing-resistant, strong authentication means to protect web users worldwide. The FIDO2 Project includes two game-changing standards that will alter the way users access and safeguard themselves on the web: WebAuthn and Client to Authenticator Protocol (CTAP). Concurrent to the forthcoming introduction of FIDO2 certification testing is the introduction of a FIDO Universal Server certification. More details follow below:

WebAuthn is a collaborative effort with the World Wide Consortium (W3C) based on Web API specifications
The FIDO Alliance and W3C stakeholders worked together to craft WebAuthn. It works by defining a standard API that can be incorporated into both web browsers and web platform infrastructure to afford users new methods of secure authentication on the web directly from their browser as well as across sites and devices. Web security is a constant source of risk for users, and WebAuthn is a hefty step toward a more secure user experience without reliance on passwords that are easily compromised. Passwords are to blame for some 80 percent of breaches, and in response, major browser platforms are moving to erase this dependency.

Client to Authenticator Protocol (CTAP) Strengthens External Authentication
External communicators, such as security keys or mobile phones, can now communicate stronger authentication credentials locally over USB, Bluetooth or NFC directly to the user’s internet access device via PC or mobile phones.

The FIDO Universal Server will ensure consistent user experience across authenticator types
FIDO is pleased to introduce a new Universal Server certification for servers that can interoperate with all FIDO authenticator types (FIDO UAF, FIDO U2F, WebAuthn, CTAP). This is anticipated to be a best practice for service providers who want to ensure that all of their consumers can leverage FIDO Authentication.

The buzz around the FIDO2 release was felt throughout RSA as we spoke with FIDO Alliance members and other conference attendees. The week was capped off by a standing-room-only session on Friday led by Google (Sam Srinivas, product management director, Google Cloud – and FIDO President) and Microsoft (Dave Bossio, group program manager, Microsoft – and FIDO Vice President) called “Replacing Passwords with FIDO2 Authentication,” which was moderated by FIDO Alliance executive director Brett McDowell.

The presenters covered how FIDO’s modern authentication ecosystem is leading the charge in browser and online platforms and the movement away from password-based authentication. Google and Microsoft security team leaders debuted the newly available authentication options built around FIDO2 and W3C standards in their browsers and other core products.

At the heart of the session was a series of demos that showcased biometric and second factor authentication scenarios across browsers (Chrome, Edge and Firefox) and operating environments (Windows 10 and Android). FIDO members Nok Nok Labs and Yubico provided the Universal Server and FIDO2 Security Keys, respectively, that underpinned the demos.

If you weren’t one of the 300+ in attendance but want to get all of the details, please be sure to register for our FIDO2 webinar on May 16, 1pm ET, which will recap the session – including the FIDO2 demonstrations.

The post RSA Conference Wrap Up: Successful Launch of FIDO2 Authentication, with More to Come appeared first on FIDO Alliance.

FIDO’s presence at RSAC 2018 is off to a strong start, coming on the heels of last week’s announcement of the FIDO2 Project, including W3C’s Web Authentication specification hitting candidate release. Attendees have had many questions about FIDO2 and in general are excited by the prospect of leading browsers supporting FIDO Authentication in order to reduce the industry’s reliance on passwords.

The FIDO ecosystem has been quite busy at RSAC — highlighted by a Passport for Strong Authentication that is encouraging attendees to visit one or more of 15 booths showcasing FIDO(R) Certified solutions. In addition, many members have issued announcements about their FIDO solutions, including:

• Infineon: RSA Conference 2018: Infineon demonstrates secured authentication using FIDO2 on Microsoft Windows 10
• Microsoft: Windows Hello and FIDO2 Security Keys enable secure and easy authentication for shared devices
• Raonsecure: Raonsecure to showcase biometric authentication solutions at RSA
• Yubico: Yubico and Microsoft Introduce Passwordless Login
• HID Global: HID Global Continues to Create and Share Authentication Best Practices at RSA 2018
• eWBM: eWBM to unveil FIDO Certified Fingerprint Authenticator at RSA 2018 in San Francisco

As always, there’s also been plenty of off-hours socializing — including the annual Non-Profits on the Loose reception, co-sponsored by FIDO, the Anti-Phishing Working Group, the Cyber Threat Alliance, the Internet Society, the National Cybersecurity Alliance and the Online Trust Alliance.

FIDO’s presence at RSAC will be capped off on Friday with a debut presentation of FIDO2 capabilities, featuring a joint presentation by Google’s Sam Srinivas (also FIDO’s president) and Microsoft’s Dave Bossio (FIDO’s vice president) – moderated by FIDO’s executive director Brett McDowell. The panel will give a first-hand look at new authentication options based on FIDO2 and W3C standards in their browsers, and is being held April 20th at 10:15am in Moscone South Esplanade 151.

Not able to attend the presentation? Fear not, as we’ll also be hosting a FIDO2 webinar on May 16 – registration details will be posted soon!

The post FIDO at RSA 2018: Spotlight on the FIDO Ecosystem, Plus Live Debut of FIDO2 appeared first on FIDO Alliance.

The FIDO Alliance has developed a framework for strong, multi-factor authentication (MFA) that is easy to use and deploy. Many enterprises have deployed federation to enable single sign-on (SSO) across on-premises or cloud applications. As enterprises consider deploying and leveraging FIDO for stronger authentication they question whether FIDO is intended to replace existing federation protocols or whether a complete overhaul is required to integrate FIDO with those existing protocols.  The answer is no: FIDO and federation protocols are not only complementary but function optimally together.

The FIDO Alliance has published a white paper detailing how FIDO complements federation protocols and providing guidelines on how to integrate the two in order to add support for FIDO-based MFA and replace or supplement traditional authentication methods in federation environments.

FIDO’s main goal is to reduce the burden of remembering  multiple passwords or having a variety of two-factor authentication form factors for separate applications. When a user registers a FIDO-enabled device (such as a Security Key or mobile device) with an application provider, a unique credential is generated and bound to the user’s account with that particular application provider. The user can use the same FIDO-enabled device and repeat the process to generate additional unique credentials for user with other application providers, without needing to carry additional devices. The credentials on the user’s device are typically locked with the same local PIN or biometric, allowing the user to authenticate across multiple applications using a single and simple gesture.

Federation protocols such as the Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) are designed to move user identity to trusted third-party authentication authorities and away from application and service providers. When a user authenticates to a trusted authentication authority, typically using a password, a time-bound assertion or token is issued for that user to present to one or multiple application providers. The user is not required to re-authenticate to the authentication authority or to every application provider, which is the definition of  SSO.  

FIDO authenticators are utilized by enterprises to authenticate a user when they initiate a ‘sign-in’ request to an application or to ‘step-up’ the authentication for a user session. In federated environments, FIDO can be deployed to support the two scenarios:

In the initial sign-in scenario, the Application Provider redirects the user to the Application Authority, in this case the SAML Identity Provider or the OpenID Connect Provider, and requests that authentication be FIDO-based. In its authentication response back to the Application Provider, the Authentication Authority would stipulate that a FIDO-based authentication occurred.  Figure 1 illustrates a generic workflow for Web SSO in a federated environment using FIDO for strong authentication.

Figure 1: Initial ‘Sign-in’ with FIDO-based Authentication

In the step-up scenario, after the Authentication Authority performs the initial user authentication with a particular authentication mechanism and having been redirected to the Application Provider with an assertion to that fact. That assertion is subsequently determined by the Application Provider to engender insufficient confidence for a particular resource request. Consequently, the Application Provider performs additional authentication using a FIDO-based mechanism or redirects the user back to the Authentication Authority with a request the user be re-authenticated with a FIDO-based authentication to supplement the prior non FIDO-based authentication, or a higher assurance FIDO-based authentication is desired to supplement a previous lower assurance FIDO-based authentication. Figure 2 illustrates a generic workflow for step-up authentication using FIDO in a federated environment.

Figure 2: ‘Step-up’ with FIDO-based Authentication

The full value of the integration of the two scenarios presume the existing applications can request of the Authentication Authority a FIDO-based authentication, or use a specific FIDO authenticator. The request for FIDO-based authentication can be explicit or implicit, by indicating a policy name or an assurance level that requires a FIDO authenticator. Alternatively, the Authentication Authority may enforce FIDO-based authentication by default for all users, a group of users or under certain conditions pre-defined by the Application Provider.

By allowing the user to register a FIDO authenticator with a trusted Authentication Authority and then utilize that FIDO authenticator across applications without needing to be registered directly with each one of them, federation enhances user experience, improves security, and “amplifies” FIDO deployment.

It is important to note that the trust model in FIDO and in federation protocols is different. 

• With FIDO, there is direct trust between the user and the Application Provider. The Application Provider deploys a FIDO server in its infrastructure to store a user’s public credential and directly authenticate users. The Application Provider is referred to as FIDO Relying Party (RP).
• With federation protocols, the trust between the user and application provider is indirect. The trust is established between the user and the Authentication Authority, and between the Authentication Authority and the Application Provider. The user authenticates to the Authentication Authority, and the Authentication Authority issues an assertion about the identity of the user to the Application Provider.

In a combined FIDO and federation environment, the Authentication Authority acts as a FIDO RP.

FIDO answers emerging needs for rapidly changing enterprise environments, but also extends and builds on legacy protocols such as federation protocols to preserve existing functions and workflows. This way, enterprises can take advantage of FIDO security and usability benefits in  the most cost effective way. To learn more, download and read the white paper. 

In the paper, you will find detailed information on how FIDO can be integrated with leading federation protocols, namely SAML, OIDC, and OAuth,  including how:

• A SAML Service Provider (SP) requests from the SAML Identity Provider (IDP) that user authentication be FIDO-based.
• A SAML IDP returns a SAML Assertion to the SP indicating that user authentication was performed using FIDO.
• A OIDC RP requests from the OIDC Provider that authentication be FIDO-based.
• An OIDC Provider returns a token to the RP indicating that user authentication was performed using FIDO, and how.
• FIDO could be leveraged in OAuth2 environments for user authentication prior to user consent and authorization to access a protected resource.

 FIDO TechNotes highlight aspects of the FIDO specifications that are important for practitioners to understand. TechNotes shed light on architectural choices, explain best practices, and give guidance to deployers of the technology. TechNotes are part of an on-going FIDO series featuring the technology and evolution of the FIDO Alliance.

The post FIDO TechNotes: Is FIDO Intended to Replace Federation Protocols? appeared first on FIDO Alliance.

The FIDO Alliance is  pleased to announce the release of the FIDO U2F version 1.2 specification. This update has been published as a “Proposed Standard” and comes after several months of work by FIDO members. The changes include:

• Improvements to JavaScript and MessagePort APIs
• U2F metadata statement support
• Attestation Certificate X.509 Transport extension added
• Silent-authentication mode added
• Various fixes and editorial updates

Silent authenticator support is the highlight feature of this update.  It is particularly useful to FIDO-based federated solutions that need silent mode for “bearer token” like authentication modes. The major advantage of FIDO-based solutions is that key material cannot be compromised. Since FIDO protocols are based on digital signatures, and the private key is stored generally in secure enclaves, federated identity schemes can use the authenticator as an unrecoverable bearer token, and not worry about cross-site scripting (XSS) and malware on the client side.

With added support for Metadata Statements, vendors now can register FIDO U2F authenticators with a metadata service. This is particularly useful for service providers  who would want to restrict the types of the authenticators they accept. For example, a service provider may  only allow  FIDO Certified authenticators, or it may be required by regulation to only accept government-approved authenticators supporting particular protocols or certifications, such as FIPS, CSPN, AFSCM and others.

Another interesting feature is FIDO U2F X.509 Transport Extension. This gives service providers a better picture of the types of authenticators the user has, which helps improve the user experience.

Other changes include improved JavaScript API (JSAPI), U2FHID ISO enhancements, and forward compatibility with FIDO2.

For a detailed overview refer to our extended overview blog; “FIDO TechNote: A Detailed Look at FIDO U2F v1.2 ”

The post Introducing FIDO U2F v1.2: Changes Overview appeared first on FIDO Alliance.

The FIDO Alliance is  pleased to announce the release of the FIDO U2F version 1.2 specification.

Since the last two versions, there’s been structural changes, improvements, updates and new security features. Below, we take a detailed look at these changes. For a summary version of the changes, go to “FIDO U2F v1.2: Changes Overview.” 

JS API

interface u2f {

  void register (

      DOMString appId,

      sequence<RegisterRequest> registerRequests,

      sequence<RegisteredKey> registeredKeys,

      function(RegisterResponse or Error) callback,

      optional unsigned long? opt_timeoutSeconds

  );

  void sign (

      DOMString appId,

      DOMString challenge,

      sequence<RegisteredKey> registeredKeys,

      function(SignResponse or Error) callback,

      optional unsigned long? opt_timeoutSeconds

  );

};

High level JS API has been updated. Previously, you had to individually set,every “RegisterRequest” and “SignRequest” appId and challenge. In JS API v1.2 appld is passed as a first argument for u2f.register.

/* —– U2Fv1.0 —– */

let appId     = “https://example.com“;

let registerRequests = […];

let signRequests     = […];

for (let regReq of registerRequests) {

  regReq.appId = appId;

}

for (let signReq of signRequests) {

  signReq.appId = appId;

}

u2f.register(registerRequests, signRequests, () => {

  …

})

/* —– U2Fv1.2—– */

let appId     = “https://example.com“;

let registerRequests = […];

let signRequests     = […];

u2f.register(appId, registerRequests, signRequests, () => {

  …

})

Another way that v1.2 has been redefined is authentication request dictionaries. Previous dictionaries of type “SignRequest” have been replaced by “RegisteredKey” dictionary.

/* —– U2Fv1.0 —– */

dictionary SignRequest { // OLD

DOMString version;

DOMString challenge;

DOMString keyHandle;

DOMString appId;

};

/* —– U2Fv1.2 —– */

dictionary RegisteredKey { // New

DOMString version;

DOMString keyHandle;

Transports? transports;

DOMString? appId;

};

With this change, the challenge has been removed from the dictionary and is now the second argument of the u2f.sign command The first is appId, same as for the u2f.register command.

/* —– U2Fv1.0 —– */

let appId     = “https://example.com“;

let signRequests = […];

for (let regReq of registerRequests) {

  regReq.appId = appId;

}

u2f.sign(signRequests, () => {

  …

})

/* —– U2Fv1.2 —– */

let appId     = “https://example.com“;

let challenge = “YJjw3jBh6RiMPKY0lMWq8GXm0Qap”;

let registeredKeys = […];

u2f.sign(appId, challenge, registeredKeys, () => {

  …

})

For backward compatibility, the client may still process SignRequest. The same applies for an RP, who may continue processing SignResponse.

Another added feature is “transports” array. The RP may indicate to the client which transports a particular key handle uses. It does so through the use of the Transport enumeration:

enum Transport {

  “bt”,   // Bluetooth Classic (Bluetooth BR/EDR)

  “ble”,  // Bluetooth Low Energy (Bluetooth Smart)

  “nfc”,  // Near-Field Communications

  “usb”,  // USB HID

  “usb-internal” // Non-removable USB HID (built in)

};

This is particularly useful for UI/UX, where the client can refer to the prompt that is specified by the indicated transport.

We will discuss transport detection in the “Authenticator Transport Extension” section.

The MessagePort API gained it’s own request definition dictionary IDL.

dictionary U2fRequest {

  DOMString      type;

  DOMString?     appId;

  unsigned long? timeoutSeconds;

  unsigned long? requestId;

};

That extends to “U2fRegisterRequest” and “U2fSignRequest”

dictionary U2fRegisterRequest : U2fRequest {

  DOMString                 type = ‘u2f_register_request’;

  sequence<RegisterRequest> registerRequests;

  sequence<RegisteredKey>   registeredKeys;

};

dictionary U2fSignRequest : U2fRequest {

  DOMString               type = ‘u2f_sign_request’;

  DOMString               challenge;

  sequence<RegisteredKey> registeredKeys;

};

As you can see, the changes that happen to the U2F JS API, happen correspondingly to the MessagePort API as well.

/* —– U2Fv1.0 —– */

var port = <obtain U2F MessagePort in a browser specific manner>;

port.addEventListener(‘message’, responseHandler);

port.postMessage({

‘type’: ‘u2f_register_request’,

‘registerRequests’: [<RegisterRequest instance>, …],

‘signRequests’: [<SignRequest for known token 1>, …],

‘timeoutSeconds’: 30,

‘requestId’: <unique integer>  // optional

});

/* —– U2Fv1.2 —– */

var port = <obtain U2F MessagePort in a browser specific manner>;

port.addEventListener(‘message’, responseHandler);

port.postMessage({

‘type’: ‘u2f_register_request’,

‘appId’: <Application id>,

‘registerRequests’: [<RegisterRequest instance>, …],

‘registeredKeys’: [<RegisteredKey for known token 1>, …],

‘timeoutSeconds’: 30,

‘requestId’: <unique integer>  // optional

});]

Authenticator Transport Extension

During registration, the authenticator signs the challenge with a batch key, and provides its public key with an X.509 certificate. The vendor now can add X.509 FIDO OID’s and U2F certificate extension that will identify that this is a U2F authenticator certificate:

— FIDO Alliance’s OID

id-fido OBJECT IDENTIFIER ::= 1.3.6.1.4.1.45724

— FIDO U2F protocol OID

id-fido-u2f OBJECT IDENTIFIER ::= { id-fido 2 }

— FIDO U2F certificate extensions arc

id-fido-u2f-ce OBJECT IDENTIFIER ::= { id-fido-u2f 1 }

To identify the type of the authenticator, the specification defines U2F Transport Extension

— FIDO U2F certificate extensions

id-fido-u2f-ce-transports OBJECT IDENTIFIER ::= { id-fido-u2f-ce 1 }

fidoU2FTransports EXTENSION ::= {

  WITH SYNTAX FIDOU2FTransports ID id-fido-u2f-ce-transports

}

FIDOU2FTransports ::= BIT STRING {

  bluetoothRadio(0),– Bluetooth Classic

  bluetoothLowEnergyRadio(1),

  uSB(2),

  nFC(3),

  uSBInternal(4)

}

Raw Message Format

One of the most important features of this update is added silent authenticator support. With this feature, Application Protocol Data Units (APDUs)  received new sign parameters dont-enforce-user-presence-and-sign(0x08). Now clients can request signature without user presence enforcement. This is particularly useful to FIDO-based federated solutions that use silent mode for “bearer token” like authentication modes. The major advantage of FIDO-based solutions is leakage resilience. Since FIDO protocols are based on digital signatures, and the private key is stored generally in secure enclaves, federated identity can use the authenticator as an unrecoverable bearer token, and therefore not have to worry about XSS and malware on the client side.

U2FHID

U2FHID was updated with a U2FHID_LOCK command. Now the client can request the authenticator to lock communication only to one channel for up to 10 seconds. The client can continuously send LOCK command to extend authenticator lock time.

Metadata Statement

U2F has received support for metadata statements.

{

  “description”: “FIDO Alliance Sample U2F Authenticator”,

 “attestationCertificateKeyIdentifiers”: [“7c0903708b87115b0b422def3138c3c864e44573”],

  “protocolFamily”: “u2f”,

  “authenticatorVersion”: 2,

  “upv”: [

      { “major”: 1, “minor”: 2 }

  ],

  “assertionScheme”: “U2FV1BIN”,

  “authenticationAlgorithm”: 1,

  “publicKeyAlgAndEncoding”: 256,

  “attestationTypes”: [15879],

  “userVerificationDetails”: [

     [{ “userVerification”: 1 }]

  ],

  “keyProtection”: 10,

  “matcherProtection”: 4,

  “attachmentHint”: 2,

 “isSecondFactorOnly”: “true”,

  “tcDisplay”: 0,

  “attestationRootCertificates”: [

      “MIICPTCCAeOgAwIBAgIJAOuexvU3Oy2wMAoGCCqGS

      VdLIgtfsbDSu7ErJfzr4AiBqoYCZf0+zI55aQeAHjI…

      lQ==”

  ],

  “icon”: “data:image/png;base64,iVBORw0KGgoAAAAUgAAAE8AAAAv…”

}

To accommodate these changes, new fields have been added, such as

• attestationCertificateKeyIdentifiers — SHA-1 Certificate SKID from RFC5280
• assertionScheme —new U2FV1BIN scheme definition

With these changes, U2F can now be added to the list of supported by Metadata Service protocols.

 — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 

If you wish to learn more about U2Fv1.2, visit the FIDO Alliance specs repository.

References

• https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html
• https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-authenticator-transports-extension-v1.2-ps-20170411.html
• https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html
• https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-hid-protocol-v1.2-ps-20170411.pdf
• https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-metadata-statement-v1.2-ps-20170411.html
• https://www.ietf.org/rfc/rfc5280.txt
• https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/

The post FIDO TechNotes: A Detailed Look at FIDO U2F v1.2 appeared first on FIDO Alliance.

Last week, Aetna’s Chief Security Officer Jim Routh told the Wall Street Journal about his organization’s pioneering efforts to improve security and usability of its online services for its customers, partners and employees. A core component of that effort is FIDO Authentication.

Aetna is now in a multi-year process of rolling out its next-generation authentication (NGA) platform across mobile and web applications. With NGA, Aetna is forging new industry best practices for improving healthcare access through a two-pronged approach to strong authentication. First, they have adopted passwordless FIDO Authentication with biometrics for their customers’ online account credentials, reducing their reliance on highly vulnerable “shared secrets,” like passwords and one-time-passcodes with strong, unphishable, public key cryptography.

Routh recently talked about Aetna’s FIDO adoption: “Aetna adopted the FIDO standard for biometric information to create consistency and simplify the entire authentication process. FIDO insulates us from the implications of the consumer choice or the security functionality that is built into the device. The standard separates the authentication process from an application developer so regardless of the configuration of mobile carrier, device maker or online service, we can authenticate every time. More importantly, our member’s biometric information never leaves his or her device, ensuring the member’s identity remains protected and uncompromised.”

We applaud Aetna’s commitment to consumer choice and creating a more unified experience throughout its services with single-gesture, FIDO-based biometric authentication. Adopting FIDO also will help Aetna protect its customers, partners and employees against phishing, man-in-the-middle and other attacks often used to harvest traditional user credentials.

While deploying standards-based strong authentication like FIDO helps resolve many of the authentication problems organizations have faced around security and user experience, healthcare providers still have to contend with risks associated with lost and stolen devices. Thus, Aetna is rolling out the second core component of the NGA platform — continuous, behavior-based authentication — to ensure that the authenticated user is the same person throughout the lifetime of the session. To do this, Aetna looks at several user attributes (such as the way they hold their phone) and assigns risk scores to determine how much access to give a user during a session. If high risk is detected during a session, Aetna may challenge the user for additional information before allowing continued access from that device.

Aetna’s rollout of FIDO Authentication plus continuous, behavioral authentication should go a long way towards combating the growing threats against sensitive healthcare data. It couldn’t come at a better time, as 36 percent of all breaches and 44 percent of all records compromised in 2016 were healthcare-related, and account takeover attempts are at an all-time high.

Aetna has set the bar for remote authentication and access management of sensitive healthcare data. They have done this in a way that improves patient and provider access to the data while simultaneously improving the protection of that data; the classic “win win” situation we designed the FIDO standards to enable service providers to achieve. While this is a great milestone for an industry in need of innovative solutions, it is only the beginning of FIDO Authentication in healthcare. I anticipate that other healthcare organizations will follow Aetna’s lead and either replicate or leverage the platform Aetna has put in place to deliver more convenient, stronger authentication leading to increased patient record access and decreased data breach metrics across their highly targeted industry.

The post Setting the Standard for Healthcare Security: Aetna Rolls out FIDO and Behavioral Authentication appeared first on FIDO Alliance.

The ecosystem of products supporting FIDO Authentication continues to expand, with the number of FIDO® Certified devices pushing past 360. The FIDO Certified program provides assurance of compliance to FIDO standards, and has been a central component to achieving the Alliance’s vision for universal and interoperable strong authentication.

Companies with newly certified products include: HYPR Corp.; ING; kt ds; Pramati Technologies; Shenzhen National Engineering Laboratory of Digital Television Co., Ltd.; Uni-ID Technology (Beijing) Co., Ltd.

Functional certification lets organizations test and validate their FIDO implementations to prove their products conform to FIDO specifications and work with other certified products. The growth of the program since its launch just two years ago demonstrates that, globally, technology providers, service providers and enterprises not only understand the importance of certification when implementing and/or deploying FIDO authentication, but require it.

Interested in becoming FIDO Certified? The most common question we get is “What are the steps to becoming certified?” It is a very straightforward four-step process:

1. Sign up for the test tools and complete Conformance Self‐Validation, where the test tools are used to validate that your implementation conforms to the FIDO specifications.
2. Complete Interoperability Testing, where testing is performed at a proctored event or On-Demand to ensure that implementations are functional and compatible with other implementations.
3. Complete the Certification Submission, where all the required documentation is submitted as a request for certification.
4. Decide on exercising the optional Trademark Usage policy. After executing the Trademark License Agreement, implementers may use the FIDO® Certified mark and logo on their product, packaging, and marketing literature.

Check out our previous certification updates to learn more about the the value of FIDO certification and how to make the most of FIDO certification. We also are looking forward to new certification programs being developed to accommodate new specifications and maturing requirements for organizations implementing and deploying FIDO-based solutions. Look for announcements in the upcoming months.

The post Certification Update: FIDO Certified Products Top 360 appeared first on FIDO Alliance.

“How does FIDO Authentication fit with Mobile Connect?” We’ve heard this question with growing frequency since this year’s Mobile World Congress, and it has also been a core topic of discussion at our FIDO seminars earlier this month in Paris and Barcelona. In order to fully answer that question, we are pleased to announce a new liaison partnership with GSMA, the organization representing mobile operators worldwide. Together, we will explore how FIDO Authentication and Mobile Connect fit together from both a technical and market perspective.

GSMA’s Mobile Connect provides a universal login solution that matches users to their mobile device, allowing them to log into websites and applications without usernames and passwords. The vision of Mobile Connect, according to GSMA, is “simple, secure and convenient access to online services via your mobile device, anywhere,” a vision that aligns with the FIDO Alliance mission of simpler, stronger authentication.

There are many ways in which FIDO Authentication complements Mobile Connect, one of the most prominent being the shared use case of leveraging mobile devices for passwordless authentication. Additionally, both organizations place great value on protecting sensitive user information — with FIDO not sharing any user authentication data and Mobile Connect only sharing personal information with explicit end-user permission.

The ecosystem of FIDO® Certified devices in market is large — we estimate that hundreds of millions of handsets have shipped that can support FIDO Authentication. This opens up the opportunity for Mobile Connect to leverage the FIDO ecosystem to expand the range of authentication options offered to Mobile Connect users, allowing them to use, for example, the built-in biometric authenticators on smartphones, tablets, and notebook PCs. In turn, this will expand the reach of the FIDO ecosystem, as Mobile Connect has already been launched by 52 operators in 29 markets.

We are looking forward to this liaison partnership, and an in-depth exploration of how FIDO Authentication and Mobile Connect combined can help users transact more safely and conveniently in our increasingly global and connected society.

The post New Liaison Relationship with GSMA to Explore How FIDO Authentication Fits with Mobile Connect appeared first on FIDO Alliance.

In the summer of 2011, users in Iran were subject to a man-in-the-middle attack: Someone had stolen TLS certificates from the Dutch Certification Authority DigiNotar, and was using them to impersonate Google and many other destinations on the Internet in Iran. In addition to eavesdropping on their victims, this attacker could have easily stolen cookies and passwords, allowing them to access their victims’ accounts even after the man-in-the-middle attack itself was put to an end.

The Heartbleed Bug that was discovered in 2014 leaked TLS session data from servers around the internet, again including cookies, and perhaps other user credentials such as passwords.

In March, the DROWN attack on TLS showed that many popular sites on the internet have been vulnerable to eavesdropping by men-in-the-middle. If an eavesdropper was able to collect cookies or passwords through this attack, once again users would remain vulnerable even after the attack had been neutralized.

The reason users remain vulnerable even after these kinds of attacks are shut down is that we use bearer tokens for authentication on the internet. A bearer token is a secret that a client comes bearing to the server in order to convince the server that it should be granted access. It’s in the nature of bearer tokens that they can fall into the hands of eavesdropping men-in-the-middle.

FIDO represents a large and concerted effort by more than 250 companies to rid the internet of one of the most notorious bearer tokens: the account password. Instead of a password, FIDO uses a private key as the account credential, which never leaves the user’s computer. If all users subjected to the attacks above had been using FIDO authentication, attackers who are after account credentials would have come away empty-handed.

But account credentials are not the only prize to be gained from such attacks. As already mentioned, cookies can be just as valuable to attackers as passwords; and this list also includes OAuth tokens or other bearer-token session credentials. In order to protect users from attackers that remove such session credentials from one TLS connection and re-use them elsewhere, it is considered good practice to channel-bind session credentials. This means that the session credential (the cookie, the OAuth token, etc.) itself is tied to the underlying TLS connection over which it is sent. If a man-in-the-middle or other credential thief tries to use the credential in another context (i.e., over another TLS connection), the credential will be considered invalid. The original RFC for channel binding specifies two ways of doing this: either by tying the credential to the server certificate, or to a unique “fingerprint” of the underlying TLS connection. Unfortunately, neither of these channel-binding techniques are practical for cookies, which are created by the server and sent to the client; and then frequently (re-)sent by the client over different TLS connections to the server.

Google, Microsoft and others have therefore experimented with a different channel-binding technique, which instead binds the session credential to a client’s key. This means that a server can associate – as it creates a new cookie for a client – this cookie with the client’s public key. Later, when the client sends the cookie back to the server, it must prove possession of the corresponding private key. A cookie thief not in possession of this private key won’t be able to use the stolen cookie.

This technique has gone through a number of iterations (being called “Origin-Bound Certificates” and “Channel ID” along the way), and is currently being standardized by the IETF under the name of Token Binding.

To summarize: in order to deny man-in-the-middle attackers the ability to re-play credentials obtained from eavesdropping on their victims, sites on the internet should use FIDO authentication (to eliminate the risk of stolen passwords) and channel-binding techniques such as Token Binding (to eliminate the risk of stolen cookies). These technologies complement each other, and can be deployed independently.

What we described so far (replacing passwords with client-held key pairs, and channel-binding cookies) would leave one small window of opportunity for an eavesdropper. At login time, the client usually sends a FIDO assertion (i.e., a signature generated with the user’s private key over a server-generated challenge) to the server, which checks it and in return sends a channel-bound cookie back to the client. What if the man-in-the-middle managed to steal that FIDO assertion? The attacker wouldn’t know the user credential (which is a private key safely stored on the client device), but it would have access to the FIDO assertion, and be able to exchange it for a cookie that would then be bound to the attacker’s client instead of the legitimate user’s device. This amounts to hijacking the user’s login session.

FIDO therefore specifies that FIDO assertions can themselves be channel-bound. This means that before sending the FIDO assertion to the server, the client includes information about the TLS connection between client and server into the FIDO assertion, binding it to that TLS connection. FIDO UAF allows all channel-binding mechanisms from RFC 5929, plus Channel ID, whereas FIDO U2F only allows Channel ID. (Token Binding, which replaces Channel ID, wasn’t an IETF draft at the time the FIDO specifications were written. It’s a trivial change in the FIDO specifications to switch from Channel ID to Token Binding.)

Note that the addition of channel-binding information in FIDO assertions is optional: not all client platforms support Channel ID or Token Binding, and even if a client has all the necessary support for channel-binding, it might make sense not to enforce channel-binding. In other words, a FIDO relying party may want to ignore the channel-binding information in FIDO assertions, and choose not to channel-bind its cookies.

Why would a relying party choose not to make use of this extra security measure? Some client networks have deployed proxy servers at the perimeter of their network. These proxies inspect outgoing and incoming traffic for viruses, potential leaks of trade secrets, etc. It’s in the nature of these proxies that they break the channel binding of FIDO assertions or channel-bound cookies. While such networks won’t be able to enjoy the full man-in-the-middle protection of channel-binding, they can still benefit from the security and usability improvements of FIDO authentication.

Therefore, relying parties should be mindful when they do and do not enforce channel binding of cookies and FIDO assertions. For example, they can let users (or enterprise administrators) decide which accounts should be exempt from channel binding. Users or enterprises could choose to opt out of channel binding if they operate in an environment where TLS traffic is being intercepted, while still using FIDO authentication.

To recap: in this TechNote, we discussed three ways to move from bearer tokens (which are susceptible to theft by eavesdropping men-in-the-middle) to more secure forms of authentication:

1. Use FIDO authentication instead of (or in addition to) passwords. This is what the FIDO specifications are all about. The benefits here are tremendous: today, most account takeovers stem from phishing attacks or breach of password databases. Both of these attacks are rendered impossible when relying parties adopt FIDO authentication, regardless of whether they also deploy the other two mechanisms below.
2. Enforce the channel-binding in FIDO assertions. This is an optional part of the FIDO specification, and depends on the capabilities of the client (does it support Channel ID? Other forms of channel binding?, etc.), as well as the requirements of the client (do they need to intercept TLS traffic before it leaves the client premises?). FIDO relying parties – presumably after consulting with their clients – can choose from a range of options here, including only allowing clients that support channel binding (and enforcing it), ignoring channel-binding information altogether, or something in between (like treating separate user accounts differently).
3. Channel-bind the cookies that the server issues. This is outside the scope of the FIDO specifications, and can be done independently of any FIDO deployment. (For example, a server could issue a channel-bound cookie in response to a valid password, instead of a valid FIDO assertion.) Note that the same comments as mentioned above on client abilities and client requirements for man-in-the-middle protection through channel binding apply here, as well.

FIDO TechNotes highlight aspects of the FIDO specifications that are important for practitioners to understand. TechNotes shed light on architectural choices, explain best practices, and give guidance to deployers of the technology. TechNotes are part of an on-going FIDO series featuring the technology and evolution of the FIDO Alliance. Current entries include There Is No Security Without Privacy.

The post FIDO TechNotes: Channel Binding and FIDO appeared first on FIDO Alliance.

The proliferation of mobile devices leaves U.S. government agencies with a tough balancing act between security, usability and effectively performing their missions. How can they accommodate an increasingly mobile workforce that wants to use all of their devices to access online services, while adhering to a plethora of security policies and directives?

To answer the call, the Office of Management and Budget (OMB) and the National Institute of Standards and Technology (NIST) have provided agencies with exceptional options, such as derived PIV credentials (guidelines for which are outlined in NIST SP 800-157). Derived PIV credentials allow the issuance of PKI credentials, based on having a PIV smart card (and being identity-proofed prior to obtaining a PIV) on users’ mobile devices, giving them secure and flexible options to access critical apps and information.

However, deployment of these secure mobile authentication options has not matched demand. We still aren’t seeing wide deployment of mobile credentials that meet NIST guidelines and the risk profiles of agencies. In addition, the U.S. government has not consistently adopted the biometric capabilities built into most mobile device platforms as the private sector has.

There’s good news for government – FIDO authentication standards, and the devices with FIDO capability built-in, provide additional options to help agencies go mobile while staying secure and adhering to important standards and guidelines.

Going Mobile with FIDO: Usable, Secure and Private
The FIDO Alliance is improving online authentication by developing open, interoperable industry specifications that leverage device-based user verification for better usability and proven public key cryptography for stronger security. With FIDO, agencies don’t have to sacrifice usability and efficiency to obtain strong authentication for mobile access to online services.

For better usability, FIDO standards support a range of interoperable authentication factors and modalities, including biometrics built into many mobile devices today for strong authentication. For example, with FIDO, the user need only touch something (fingerprint sensor) or look at something (iris or facial recognition) on their mobile device to securely access apps and data. While these examples use biometrics, there are other non-biometric modalities supported that are still interoperable – such as a security token using Near Field Communication (NFC) – should a portion of the workforce not choose a biometric option.

There is already a rich set of products ready for FIDO deployment – more than 150 products have been tested and FIDO Certified from over 60 different companies, including leading mobile device manufacturers such as Samsung, Lenovo, Sony and LG. This is thanks to the FIDO certification program, which ensures different FIDO implementations interoperate with each other on a technical level and that the technical specifications are adhered to.

To match the usability with the required strong authentication needed in government, FIDO standards utilize industry standard, tested and vetted cryptographic algorithms and security mechanisms in significant use by the public and private sectors. With FIDO, you can achieve the security benefits of public key cryptography without the traditional and costly certificate authority (CA) model. In other words, it’s public key without the “infrastructure.” Additionally, if a biometric authenticator is your choice, rest assured, FIDO mandates that the biometric NEVER leaves the device, increasing privacy and security by effectively limiting the chance of a massive breach of credentials.

How FIDO Registration Works

Registration:
As detailed in the image above, registration is completed as follows:

• User is prompted to choose an available FIDO authenticator that matches the online service’s acceptance policy.
• User unlocks the FIDO authenticator using a fingerprint reader, a button on a second–factor device, securely–entered PIN or other method.
• User’s device creates a new public/private key pair unique for the local device, online service and user’s account.
• Public key is sent to the online service and associated with the user’s account. The private key and any information about the local authentication method (such as biometric measurements or templates) never leave the local device.

How FIDO Fits In: Government Use Cases
FIDO is an excellent option for any use case in which government agencies need to provide simple, fast and secure multi-factor, mobile-based authentication to digital services. Some opportunities in federal and local governments for access to government applications include:

• Derived PIV credentials
• Public safety and first responder credentials
• Emergency communications personnel credentials
• International partner credentials
• Business partner credentials
• Citizen or beneficiary access to government services
• Credentials for contractors and employees that aren’t eligible for a PIV but need secure access to online services
• Physical access control applications, i.e. using FIDO along with NFC on a mobile device

FIDO can provide the necessary usability, security, privacy and utility for all of these use cases, while helping government agencies meet security policies and directives including:

• OMB M-04-04. FIDO specifications can be implemented on platforms that support all of the levels of assurance defined in OMB M-04-04. FIDO provides one unified specification; government agencies can support FIDO-based authenticators across a range of levels of assurance (LOA) while deploying a single server-side infrastructure that supports any client-side device.
• NIST SP 800-63-2 Electronic Authentication Guidelines. With FIDO, agencies can comply with a host of token types defined in 800-63-2. In addition, FIDO authenticators that use biometrics meet the requirements of the NIST 800-63-2 Electronic Authentication Guidelines because FIDO credentials are used locally only to unlock a strong cryptographic key, and the biometric sample and template never leave the device.
• NIST SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials. FIDO authentication standards meet most of the technical requirements of NIST 800-157, and the workflow specified in 800-157 does not need to be modified to support a FIDO-compliant derived PIV credential. The only difference between a FIDO-compliant solution and the specifications within SP 800-157 is the usage of PKI.

Looking deeper at FIDO for derived PIV credentials, most of the challenges associated with such a deployment will be associated with business process, not technology. Specifically, agencies will need to define workflow that allows a user to associate a FIDO authenticator, specifically the public/private key pair, to their enterprise digital identity – just like they would for a PKI certificate. Due to the way that FIDO creates public/private key pairs in support of privacy, the agency would need to invoke the key generation process as part of an overarching identity and access management framework to ensure the public key is used for all FIDO-compliant applications, e.g. mobile applications.

In this example, the issuing entity would serve as the identity provider and the public key would need to be registered with the digital identity record of the user. From that point on, the user can use the FIDO derived PIV credential. With this type of approach, a FIDO derived PIV credential can operate in parallel and with no disruption to existing PIV- and PKI-based solutions.

FIDO for Citizens, Too
FIDO’s combination of usability, security and privacy also makes it a good option for citizen access to government online services. For citizen-facing services, EO 13681 requires agencies that make personal data available online to utilize two-factor authentication. With FIDO, agencies can meet this requirement by allowing citizens to “bring their own authenticator,” thus allowing them to use their FIDO-compliant mobile device or desktop browser to simply and strongly authenticate themselves to government services such as filing taxes, managing social security benefits, applying for student loans or submitting health insurance claims. This is not only a win for the citizen – they use what they like and already have to securely authenticate to government services. This is a win for the government too, as they don’t need to issue specialized credentials just to offer secure, privacy-enhancing multi-factor authentication for the services they provide.

Conclusion
For agencies looking to optimize security, usability, privacy, and effectively perform their missions, deploying mobile authentication for access to online services can be achieved without reinventing the wheel. FIDO’s open, interoperable industry specifications can help them obtain the best of all worlds – device-based user authentication for better usability and proven public key cryptography for stronger security and privacy.

The post How FIDO Can Help The US Government Go Mobile appeared first on FIDO Alliance.

The FIDO Alliance is very happy to announce that BC Card has been appointed to our Board of Directors. Right now, we’re seeing a great deal of innovation in authentication and biometrics coming out of Korea, and with that is coming a lot of demand for FIDO authentication.

BC Card is a great example of an innovator driving and expanding the use of open FIDO standards for authentication in Korean financial services. BC Card is a partner of Samsung Pay in Korea, which enables consumers to use FIDO(R) Certified fingerprint authentication for in-store and online payments. BC Card also uses FIDO standards to enable voice recognition authentication to replace PINs for its own in-store payment app, BC Pay.

BC Card will bring this experience and expertise to the FIDO Alliance board, and help raise awareness and promote the benefits of FIDO authentication in Korea and other markets in the Asia-Pacific region.

“As well as giving the payment service utilizing biometrics authentication, we will do our best to give the highest value to our customers through the collaboration with global companies in various industries,” said Jung Hoon Choi, senior vice president of BC Card and new FIDO Alliance board representative. “As the first FIDO Board member among the Asian financial institutions, BC Card will lead more comfortable and secure payment services based on FIDO technologies. BC Card has been actively driving market innovation, introducing a FIDO-based BC Pay voice authentication system, which is the first such application in the world, and Samsung Pay fingerprints authentication system. We are pleased to join the FIDO Alliance. Together with the FIDO Alliance, we look forward to delivering comfort and security to customers’ payment experience.”

I expect to see continuing growth in this strong momentum we’re seeing throughout Asia-Pacific, in terms of both FIDO certifications and deployments from leading technology and service providers. This week, we will host our the first ever Korean-based interoperability testing event, which will feature the largest number of of FIDO implementer companies we have ever had in a single testing event. These companies, many of which are based in Korea, will be gathering to test and validate their FIDO implementations truly interoperate with each other.

This is a sign of many more FIDO Certified products and deployments coming out of the Asia-Pacific region in the very near future. Follow @FIDOAlliance on Twitter and subscribe to our newsletter to stay up-to-date as we highlight more of this news in the coming months.  Also keep tabs on other important developments as myriad of companies and governments throughout the region deliver simpler, stronger authentication solutions using FIDO standards.

The post Momentum for FIDO Builds in Korea as BC Card is Appointed to Board appeared first on FIDO Alliance.

To understand why FIDO authentication standards were designed with a user-privacy focus, it’s important to first understand how privacy relates to security in the context of accessing online services.

Good privacy is intrinsically dependent on good security. In fact, there is no privacy without security. It’s very difficult to keep the personal information you share with an online service private if that information isn’t being properly safeguarded. Data breaches are the most common way that user privacy is put at risk online, and 95% of web app attacks make use of stolen password credentials. And, passwords are still the most commonly-used form of online authentication.

These password credentials are what we call a “shared symmetric secret;” both the online service provider and the user must know the same secret. Because passwords are human-readable shared secrets, they have many security limitations. Phishing attacks, social engineering and keystroke logging malware are just some of the ways that attackers are able to obtain passwords and use them to access their victims’ online accounts, putting consumers’ personal and financial data at risk.

With over a billion stolen passwords in circulation, it’s clear that password credentials aren’t so secret anymore. Fortunately for users, our industry has been responding to password-based attacks for quite some time with additional security measures like risk-based authentication and/or optional two-factor authentication such as a one-time password sent to a trusted device.

That being said, online security leaders know that these long-standing additional security measures are losing ground in the cybercrime battle because they share many of the same vulnerabilities as passwords, most fundamental being that they are subject to scalable attacks targeting thousands of users at once.

To get ahead of the cybercriminals, industry leaders are collaborating in the FIDO Alliance to build a set of technologies and standards for strong authentication. FIDO standards enable device-based, easy-to-use strong authentication to make scalable attacks on user credentials a thing of the past and better protect user privacy.

To accomplish this, FIDO strong authentication standards were designed with end-user privacy in mind. The protocols do not provide information that can be used by different online services to correlate and track a user across their services, because of these features:

• There is no third party in the protocol
• There are no “secrets” generated or stored on the server side
• Biometric data (if used) never leaves the device
• There is no linkability between services and accounts
• Users can de-register at any time
• There is no release of information without consent

To sum up, when FIDO authentication is implemented according to the specifications following the FIDO privacy principles, online service providers have reduced risks in the case of data breaches because no credential “secrets” are stored on their servers.

In the spirit of Data Privacy Day, follow us on Twitter @FIDOalliance all day today as we tweet about privacy and protecting data using the hashtag #PrivacyAware.

The post FIDO TechNotes: There is No Privacy Without Security appeared first on FIDO Alliance.

If you thought FIDO standards were only for FIDO Alliance member companies, think again.  Specifically, Dropbox and GitHub are not FIDO Alliance members, and NTT DOCOMO was not a FIDO Alliance member when it first deployed.  These are all examples of companies, from the outside looking in, recognize the long-term viability of FIDO protocols for strong authentication at scale. This nuance speaks volumes to the recognized maturity of these specifications less than a year from publication.

The FIDO Alliance and FIDO ecosystem have experienced a meteoric rise fueled by a 200+ member consortium and a laundry list of over 60 FIDO Certified products.

Now is the point where the story has moved on from standards development to market adoption, which ultimately makes mobile and web applications simpler and safer for end-users.

With that in mind, we introduce our FIDO Alliance blog as a place where we can continue to showcase these developments, detail FIDO’s continuing work such as certifications, and discuss progress toward a future where interoperable, easy-to-use public key cryptography will be the norm for online strong authentication.

What lies ahead are new products, further deployments, additional innovative members, formal standardizations and work toward support across many platforms.  Along the way, there are conference presentations, seminars and webinars to highlight in this blog, along with countless questions to answer. There are technical matters to explore and ultimately, the realization of a simpler, stronger authentication layer for the Internet.

All of these topics will find their way into this space.

The technology is always just the first step; it’s the cultural shift where the FIDO Alliance must shine in leading the world to simpler, stronger, universal authentication that as delightful to use as it is secure and respectful of end-user privacy.

With this blog, we’ll keep an eye on the critical developments within industry and government, along with the consumer market, where billions of people have fallen victim to breaches in the past several months.

As the Executive Director of the Alliance, I look forward to interacting with more authentication stakeholders and end users through this new communication vehicle, the FIDO blog.  So please feel free to leave comments here and/or post to our Twitter account @FIDOalliance, and we will get back to you.

Written by: Brett McDowell

The post Introducing the FIDO Blog – Featuring GitHub’s Adoption of FIDO Standards appeared first on FIDO Alliance.