The counter starts at zero and is incremented each time the device is plugged in. In other words, you can plug in the Yubikey three times a day for almost 60 years before running out of session counters. Note that you can generate a significant number of OTPs during each session see below. The following three bytes, bytes 9 through 11, are used as a timestamp, which is stored in volatile memory during each session. That means each time the device is plugged in, the timestamp starts at zero and continuously increases.
Because it is incremented by an internal 8Hz clock, timestamp values will be exhausted after about 24 days. At that time, you need to unplug the Yubikey and plug it back in. Byte 12 in the sequence is a session counter that starts at zero and is incremented by one each time a token is generated. When it reaches that maximum value of , it wraps back to zero. Bytes 13 and 14 in the sequence are pseudo-random numbers provided by a free-running oscillator.
These bytes are used to add additional entropy to the plain text before subjecting it to the cypher. The last two bytes, numbers 15 and 16, contain a checksum using the CRC algorithm over all values of the token with the two checksum bytes set to zero.
This checksum is used for data-integrity checking. Each time the Yubikey is invoked, it generates the byte sequence described above. However, if you look at the sample Yubikey output previously listed in this article, you will notice that it actually consists of 44 characters.
That is because we still are missing three crucial steps before the Yubikey is ready to spit out the final token. First, the byte token is encrypted using an AES key that is unique to each Yubikey. Second, the Yubikey prepends the encrypted byte token with a six-byte plain-text public ID.
This public ID is completely different from the secret ID used to construct the byte sequence. The public key does not change and can be used to associate a Yubikey token with an account. Finally, the whole byte sequence 16 bytes encrypted plus six bytes public ID will be encoded using the not-so-well-known ModHex algorithm. Yubico chose this algorithm simply because it is limited to characters that are common to many different keyboard layouts.
Because the Yubikey impersonates a keyboard, it tries to use characters that work with the various keyboard settings it might encounter in the wild. The disadvantage is that ModHex encoding is somewhat inefficient in that it requires two characters for each byte it encodes, which is why a byte sequence turns into a character sequence.
However, as the Yubikey does all the typing, this does not translate into an inconvenience for users. Let's take a closer look at the encryption step of generating the token. In contrast to asymmetric algorithms used in public-key encryption schemes, such as PGP, AES is a symmetric algorithm. This means both the party encrypting the token and the party decrypting and validating it will need access to the AES key!
This sharing of the AES key happens when the device is programmed. Similar to the device's unique ID, the unique AES key is generated and stored on the device by Yubico before it is shipped out. The company maintains a database where the unique public as well as secret IDs are associated with their corresponding AES keys. This way, Yubico is able to offer an authentication Web service. Using a symmetric algorithm has the advantage that it is typically very fast.
Also, you don't need to rely on third parties for key management or to vouch for identities. If you want to be in charge of your own AES key, you have two options. First, you can request your AES key from Yubico. At the time of this writing, Yubico will send you a CD containing the AES key, but the company also is working on a more convenient solution of retrieving the key on-line. Second, you can use Yubico's development kit to program the key yourself.
This way, you can assign AES keys, as well as public and secret IDs, according to your own naming conventions. If you supplement this approach by running your own authentication Web service, you eliminate any dependence on Yubico as a third party in your authentication procedure.
It's not surprising that the process of validating an OTP resembles reversing the steps necessary for constructing an OTP. A basic validation routine might look something like this. First, you ModHex decode the string. Next, you split the string into public ID and byte token. After using the AES key to decrypt, you have the original byte token in plain text.
Next, you would verify the CRC checksum the last two bytes. Then, you would compare the secret ID to the one you retrieved from the database using the public ID. Using the session counter and the session token counter, make sure that the current token was generated after the last successfully authenticated token. Although you don't know exactly when any two tokens were generated, you always can tell in which order they were generated.
If the token passes all these tests, you can send a response signaling successful validation to the client. Otherwise, the token is rejected. Optionally, you can harden the validation algorithm further. For example, you can try to calculate how many sessions or tokens have been skipped since the last successful validation and consider that information in your decision to validate or reject the token.
You can use the session timestamp in a similar manner. One thing I find really attractive about Yubico's business model is that it tries to provide all software in the form of open source. According to Yubico's statements, it plans to profit from the manufacture and sale of the devices, but intends to keep all software open source. For example, the source code for the aforementioned Web service is freely available as a reference implementation. Furthermore, Yubico offers client libraries needed for implementing Yubikey authentication in various applications and platforms.
All these libraries and programs are set up as Google Code projects. Additionally, there are projects for libraries to decrypt OTPs in C and Java, as well as an Open ID server and a personalization tool to allow you to program your own Yubikey.
Although all these software projects were initiated by Yubico, you already can see others contributing. Moreover, a number of independent open-source projects using the Yubikey technology have surfaced.
Yubico's discussion forum is a good place to keep tabs on such projects and get support. When you order a Yubikey, it comes ready to take advantage of Yubico's authentication Web service. Because Yubico maintains a database of all API keys, as well as public and secret IDs with which the Yubikeys have been programmed before shipment, Yubico has decided to offer an authentication Web service against those credentials. Developers then can use the Yubico authentication Web service to validate OTPs captured from the device.
Yubico has a Web page where you can request an API key. Anyone can get an API key. The only requirement is that you have to submit a valid Yubikey OTP.
Careers Now Hiring! Product Product Explore Our Products Duo provides secure access to any application with a broad range of capabilities. Device Trust Ensure all devices meet security standards. Adaptive Access Policies Block or grant access based on users' role, location, and more.
Duo in Action Click through our instant demos to explore Duo features. Explore Demos. You need Duo. Start a Free Trial. Duo Free Free 10 users Simple identity verification with Duo Mobile for individuals or very small teams. Pricing Questions?
Get in Touch Have questions about our plans? Solutions Explore Our Solutions Duo provides secure access for a variety of industries, projects, and companies. Customer Stories. Passwordless Authentication Users can log into apps with biometrics, security keys or a mobile device instead of a password. Already a Tech Partner?
Duo Security Solution Providers Enhance existing security offerings, without adding complexity for clients. Support See All Support Have questions? Documentation Browse All Docs Get instructions and information on Duo installation, configuration, integration, maintenance, and much more. Resources See All Resources Explore research, strategy, and innovation in the information security industry.
InfoSec Glossary. Duo Labs Research We disrupt, derisk, and democratize complex security topics for the greatest possible impact. Explore Labs Research. All new changes will be launching on Monday, 25th July In yesterday's post, we looked at how U2F security keys work.
Today we're going to look at look at how Yubico OTP works, the third and final method of two-step verification we will be supporting from tomorrow. We'll explore how it works from a technical side, and its strengths and weaknesses. A security key is a small USB device that you use to log in securely to your accounts online. While we hope the future is for U2F security keys , a super-secure open standard implemented by several manufacturers, these still have compatibility issues which mean they may not be suitable for everyone.
If you own an older YubiKey, it may only support this and not U2F. You just plug it into your computer when prompted and press the button on the top. Under the hood however, the way they work is very different! With Yubico OTP, your security key acts like a keyboard, and when you press the button it actually types in a character single-use password. The first 12 characters are a unique id that identifies the security key.
The remaining 32 characters contain a bunch of information that's encrypted with AES , crypto folks using a key known only to the device and Yubico's servers.
The information includes:.
0コメント