Forem: Dmitry Dvoinikov

Alien biohazard approach to security

Dmitry Dvoinikov — Thu, 18 Jul 2024 10:06:33 +0000

Generally speaking, security is all about threats and their mitigation. So the textbook approach is to sit down, enumerate the possible threats, write them all down and eliminate one by one.

You don't need me to tell you the ways it goes wrong.

One problem is this process is wrapped in bureaucracy, is driven by numbers and often reduced to boilerplate. Of course there must be strong passwords. Of course there must be permissions. Of course you should use SSL for transport. Of course you should not open e-mails.

By the way, here is a convenient AI-automated solution that will print you an industry standard 120 page security plan. Shareholders happy, auditors happy, good job, well done. There is very little incentive to think outside the box and stay alert, after the plan has been approved and everybody's happy.

But as you know, reality does not work like that.

Instead, the way I think about security is as if I was part of a task force landing on an alien planet. It is dangerous. It is deadly. It is full of viruses, none of which were seen before. Your equipment may be inadequate and will fail at the worst possible moment.

So what do you do all alone and vulnerable in a foreign environment which is hellbent on killing you ?

First, you set the rules and never break them. There must be a handful of basic principles, from which you don't deviate. No exceptions.

Second, you use everything you have. The measures that you take must back each other up, and be applied meticulously and in order. No shortcuts, no workarounds.

Third, you keep tightening the bolts. Look at everything as if it was about to break, the question only being when and how. Fix everything immediately, don't rest assured.

Finally, and most importantly, you plan not for safety, but for containment. The best pattern here is the airlock. One way in, one way out, designed to be locked shut and incinerated in a second.

On to the next planet.

Honor MagicBook Pro 2020 laptop, a tale of great hardware and terrible support

Dmitry Dvoinikov — Thu, 29 Apr 2021 17:29:41 +0000

This is a story of buying a Honor MagicBook Pro 2020 laptop in Germany.

As you may know, German keyboard layout is quite awkward. Not only because of the swapped Y and Z, or extra ümläütß, but most of all because the special characters are all mixed up. Makes typing a torture. And it is a primary layout, not secondary one, like Russian, where you could have QWERTY and ЙЦУКЕН sharing the same keys.

Also, good luck buying a laptop with an English keyboard in Germany. You just can't. They will gladly sell you a German keyboard, but if you want QWERTY, your only choice is to move to UK. Apple takes custom orders, but shall we say I'm not a big fan of Apple. Not to mention I was going to buy a workstation class notebook out of my own pocket.

Finally I decided to pick one and just see it through. Enter the Honor Magic Book Pro 2020.

Wonderful laptop, extremely powerful, well made and not expensive. Except for the useless webcam buried in the keyboard, everything is else is exactly what the doctor ordered for a developer's workstation. But the keyboard, the impossible German keyboard.

And so my first letter to the German Honor support goes "Can haz QWERTY ?" Got no response at all.

Tried UK support with "Can haz QWERTY delivered to Germany ?" Got an immediate "No, go ask Germany"

Second attempt with German support. "Can haz QWERTY plz ?" This time the response was fantastic: "No it is not possible, but buy one from ebay and give me a 5 stars feedback for this answer." Signed "Karl". Let's call him "Karl from Honor".

Well, I got to ebay, and found what I needed from helloworld2003. This guy turned out more helpful than all the official support. A couple of weeks later I got the laptop in my hands and let me just tell you, it's as impressive as I hoped.

And I was ready to see Chinese Windows 10 too. Reinstalled the English one clean, went without a hitch, except for the fingerprint scanner was not recognized.

Ready for the second round of support ?

Here goes: "I did as official support suggested, can haz driver plz ?" Response: "All support for Honor products manufactured before 2021 is done by Huawei, go ask them."

Now to Huawei: "Here is the entire story, can haz driver plz ?". Guess who replied from Huawei ? Karl from Honor ! Here is the answer: "We don't have drivers here. Besides, we are German, and you have a Chinese product, go to where you purchased it."

It is almost like those businesses don't need customers.

In the end, I wrote to the ebay's seller and asked for a driver. He replied in a few minutes with a direct download URL.

And the laptop itself is excellent:

The latest 6-core Ryzen 5 works on par with 8-core i9-9880H and beats my 16-core dual Xeon under-the-table workstation.
No 4K resolution, just a faithful FullHD on a reasonably bright matte 16". Also, no touch screen.
No numpad, allowing for the keys to be large, the touchpad to remain the middle, and the entire thing to stay symmetric. The keyboard and the touchpad feel nice.
Can connect two external displays, one via HDMI and one via USB-C.
Thin and light, almost funny light for a "serious" machine. Quiet and effectively cooled.
Looks really good.

On the down side:

To put a webcam underneath the screen is short of sabotage.
F12 is the same key as Ins. You either have F-keys without Ins, or Ins with all kinds of multimedia keys.

Overall, highly recommended !

First things security

Dmitry Dvoinikov — Thu, 12 Nov 2020 09:43:44 +0000

Security is a state of mind, not a state of things.

Security of things cannot be achieved. Any system that is complex enough to be secured, is already broken. This is the same kind of broad sentiment as "we'll all die eventually", but it is true. Therefore, you should always start with the premise that your security is broken - then what ?

At this moment you should think about alternative plans and insurance. In a sense, insurance is the security decision that covers risks that cannot otherwise be covered, such as death.

From a technical perspective, that all security is broken, leads to two conclusions. First, you must know when to stop being paranoid and give up some of the steps that are hopeless anyway. Second, you should make your security partitioned / layered.

Partitioning a complex system into components / modules / what have you, is the ultimate analysis principle. It makes things observable, easier to reason about, modify and replace, and, in case of security, they back each other up. When you have a row of ten doors, the attacker has to break ten locks.

On the other hand, when you partition a system, any system, it only creates an illusion that complexity disappears. Complexity, like energy, never disappears, it only transforms from one state to another. Here, the complexity goes into the interconnections. It is good when you have ten doors one after another, but in reality the parts communicate with each other in a twisted and unpredictable way. And then, another, opposite, security maxim says that the attacker must break just one door, whereas the defender must protect them all. Therefore, the more parts, the more vulnerable the system is. Catch-22.

Good luck.

Learning FPGA programming, key points for a software developer (part 3, code patterns and inferred behavior)

Dmitry Dvoinikov — Mon, 03 Aug 2020 08:50:35 +0000

The previous parts of this article discussed the time and registered logic. This part is specifically about writing VHDL. It opens with general discussion and then presents code samples and analysis.

VHDL is a declarative language, in which you declare an intent, and let the compiler find the way of implementing it. In a good declarative language it must be easy to express the intent, and the intent must be clear from the code.

You know what other common language is declarative ? SQL. VHDL and SQL are absolutely unrelated of course, but for an opening illustration SQL could be useful.

So, in SQL you write queries that manipulate data. Consider the following simplest SQL query:

SELECT x FROM t WHERE y = 1

The intent here is to find matching records from relation t and return a set of rows with just x in them. But it would be a mistake to assume that the engine would go through table t, check every record for equality of y and extract x from each. Why ?

Because nothing even indicates that t is a table and either x or y are fields. t could be a view, and x and y could be calculated expressions, even constants. In the latter case no data access would be required at all. But even if, we have no idea how it is going to be accessed. SQL optimizer might decide to read an index, rather than the table, and then depending on its coverage, a lookup to the table may or may not be required. Also about indexes, nothing suggests that a suitable index exists, heck, that the engine supports indexes in the first place.

Therefore, to write an efficient SQL query you must take a lot vendor-specific things into account. You may want to read query plans, rearrange the query and even resort to optimizer hints. The query could run either way, but could turn out impractically slow.

Same is true about VHDL.

But VHDL is poorly suited for the job. That it looks like a regular imperative language with conditions, loops, functions and even class-like protected structures, suitable for general programming, is extremely misleading. It doesn't follow a theoretical model the way SQL does, nor does it have first class representation for the objects it actually manipulates.

You should not read nor write VHDL as you would Ada (or Pascal). Instead, you should look at VHDL program the same way the compiler does. And when I say "compiler", I mean the entire chain of tools, or any one in particular.

What's the purpose of the compiler ? To turn your code into a binary configuration file for a particular FPGA device. And every device is different, vendors compete by embedding various reusable blocks. Memory blocks, arithmetic units, all kinds of controllers and even entire CPU's make their way to an FPGA chip. Then where one compiler could use a ready block, another will have to implement it from smaller bricks.

The smallest bricks in FPGA are LUT's (programmable wires) and registers. These are effectively the two kinds of objects we have in a VHDL program. Except for vendor-specific attributes (a-la SQL hints) we never mention anything else. How would a compiler know when to reuse a bigger block, when all it sees is wires and registers ? Besides, even with wires and registers, the best way to arrange them depends on the situation, but how would a compiler even know what the intent was ?

It would help, if the compiler knew what we meant from what we wrote.

The compiler tries to guess the meaning by looking for certain patterns in the code. Once a pattern is detected, an expected behavior is inferred and a known solution is applied, hoping that it is correct and efficient.

As with SQL, it may or may not be, and it is inevitable that we have to read the compilation reports and make sure there is no blunder.

Let's have some examples.

1 . The simplest pattern is this:

c <= a * b

is clearly a multiplication, and an embedded multiplier could be used, or a specific algorithm, depending on how large a and b are.

2 . This here

v: std_logic_vector;
if v = (others => '0') then

infers a zero comparator. Notice that it is different from a general comparator

v1, v2: std_logic_vector;
if v1 = v2 then

and that they produce quite different configurations.

3 . Patterns could span multiple lines, and as such are more like wildcard fragments in the parsing tree. This here

if cnt = 0 then
    ...
else
    cnt <= cnt - 1;
end if;

is a counter pattern. Again, notice how counting up produces a very different configuration

if cnt = max then
    ...
else
    cnt <= cnt + 1;
end if;

and is also somewhat less clear, even when max is a constant.

4 . In some cases there is no way the compiler could correctly guess the intent from the declaration and you have to use a vendor-specific attribute:

type ram_t is array (0 to 63) of std_logic_vector(0 to 7);
signal ram: ram_t;
attribute ramstyle: string;
attribute ramstyle of ram: signal is "MEMORY BLOCK";

With this attribute set, the compiler would utilize the embedded block memory the device might have, and without it, it would have just wasted a lot of precious registers.

Undoubtedly there are a lot more cases, but you get the idea.

Another thing, which may not be a pattern per se, but is similar in concept, and made an important paradigm shift for me was about functions. In software we think of a function as of some kind of generator, something that takes inputs and produces output. As if a new object is instantiated inside the function from the input arguments and returned as a new entity.

VHDL functions should be read differently - all they do is transform input signals to output signals. This way, a VHDL function is a wiring fragment, not a generator. So where in C you had

int add(int a, int b) {
    return a + b; // create a new int and return it
}

in VHDL you have

function add(a: integer; b: integer) return integer is
begin
    return a + b; -- wire a and b together and stick new wires out
end;

and from this observation there is just one step to looking at VHDL code like this:

all VHDL code is just wire fragments decoupled by registers.

Next, I'd like to give you the most important pattern of all, the component itself.

You see, most of the components that you have look like this:

entity edge_detector_with_passthrough is
    port
    (
        clk:      in std_logic;
        i_input:  in std_logic;
        o_output: out std_logic;
        o_edge:   out std_logic
    );
end edge_detector_with_passthrough;

architecture mixed of edge_detector_with_passthrough is

    signal b_input: std_logic;

begin

    o_output <= i_input;

    process (clk) is
    begin

        if rising_edge(clk) then

            b_input <= i_input;
            o_edge <= '0';

            if i_input /= b_input then
                o_edge <= '1';
            end if;

        end if;

    end process;

end mixed;

and the reason for this is, lacking better form of expression, by writing the code in this exact way, we telegraph our intent to the compiler. Specifically, in the above code, when we write

if rising_edge(clk) then

it doesn't mean that we are interested in the actual edge of the clock signal. Instead, we mean that

everything that happens inside that "if" is supposed to be synchronized with the clock signal (i.e. registered)

If you look closely, you see that there are two identically looking signal assignments:

o_output <= i_input;
b_input <= i_input;

but when the first one resides in a combinatorial (i.e. unregistered) area of the component, it gets translated to a direct wire, the second happens to be inside the synchronized block and therefore a register is inferred between b_input and i_input. Similarly o_edge becomes registered just by the fact of being assigned from inside the registered block. Which gives you the following diagram:

Finally, there is a case when it's not even what you wrote that affects the the compiler output, but what you didn't write. I'm talking about latches.

The following fragment

architecture latched of latch is
begin

    if i_enable = '1' then
        o_output <= i_input;
    end if;

end latched;

is hardly worth a second look, but is actually a quite important case of a missing "else". There is no else, you see. From software perspective, it's perfectly normal, if you do nothing, nothing happens.

But as this code resides in the combinatorial area of the component, it describes direct wiring of signals and reads "if enable is high, pass input to output". But what happens to output otherwise ? Unlike in software, nothing cannot happen in hardware. Output must be provided in any case, and if enable is low, we need to keep the previous input somewhere and pass it to output, to create an illusion that "nothing happened". Therefore, in this case a latch is inferred to hold the signal while enable is low.

The moral here is that VHDL makes writing clear programs quite problematic. There is no domain-specific syntax in the language and no first class objects. Therefore, rather than simply declaring the intent, you have to second guess the compiler and write spell-like constructs.

Why it turned out this way, I could guess that back in the days Ada was some kind of a military standard language, and when a committee decided what to use for VHDL, they did what committees do best - stick to the standards. Alas.

Anyway, thank you for reading and I'll be happy to talk to you later.

Learning FPGA programming, key points for a software developer (part 2, registered logic)

Dmitry Dvoinikov — Mon, 27 Jul 2020 13:01:56 +0000

The first part of this article discussed the importance of time in an electrical circuit, of which a VHDL program is a schematic. You may want to read it before proceeding.

As a summary, an electrical circuit depends on the coordinated delivery of its input signals, before it could produce a valid output.

On the face of it, we could wire any number of circuits together, activate the top-level inputs, and then just wait for the entire maze to flush through and yield stable output after some time.

It could work for some circuits, and when it does work, this approach is the fastest, I guess, because it's basically limited with the speed of light. But it doesn't work in all cases.

One reason why it doesn't, is that circuits can be so twisted that they simply won't stabilize over time, and never provide output.

The simplest such case is a feedback loop, when a circuit's output is directly or indirectly plugged into its input. Under such conditions, the circuit could go into an indeterminate state forever.

A combinatorial approach whereby you just wire blocks together thus has its limits. And the problem of stable inputs arriving to a circuit at the same time is still there. How is it solved ?

To ensure that the signals that cross boundaries between combinatorial blocks are stable and synchronous, they are held in a buffer between the blocks, until all of them arrive and stabilize. This buffer is called register.

This looks good but now we have a different problem. How does the register know for how long to hold its input and when to pass it through ? It is nothing but a wired circuit itself after all.

To solve it, a clock is introduced.

A clock is an external source of a periodic pulse, connected to every register in the system with a dedicated line.

All the registers in the system pass their input to output at clock tick, thus conceptually at the same time.

When we decouple multiple combinatorial circuits with registers, we get a bigger registered or synchronous circuit. The are two important things to observe about it.

First, there is still no guarantee that clock tick arrives at the moment when output is stable, because combinatorial circuits generate it asynchronously, with no respect to any clock. This will still fail to pass the correct value:

To make sure it does not happen, the combinatorial components must play by the clock rules and have their outputs stabilized after the last tick, but before the next. This effectively means two things:

They should only accept registered signals for their inputs. Any input signal not synchronized with the same clock is a risk to stability.
They must be simple enough to propagate the signal in the limited time they have between the clock ticks.

Second, the earliest moment when a value will appear at the other side of the register is at the start of next tick, even though it became available long before that.

Therefore a registered circuit makes a pipeline, in which signal values propagate one leg at a time, and not immediately from start to finish as before. And the earliest moment when a sequence of N registered components will produce the final output is N times tick duration.

From the above pipeline you could see that we get in 300 nanoseconds what we could otherwise get in 3, and if we wait for the output, then at any time 3/4 of the circuit is not doing any productive job. That's a lot of waste but it is the price to pay for stability.

Now, this was all about hardware.

From the software developer's perspective, there are a few things to notice.

The most important thing is that when you are working with registered signals, you are, figuratively speaking, turning yesterday's values into tomorrow's values.

Any registered signal assignment will have effect only in the next tick, even observed by the same component.

Another important thing is that

registered signal exchange between components takes very significant amount of time.

In software, we assume that calls take no time compared to the processing. We factor our programs freely into processing modules of all kinds, components, classes, functions, along the domain objects, and call one from another without second thought. But in hardware, it's the opposite: processing happens at the speed of light, but every registered signal exchange adds an extra clock cycle, thus decimating the performance.

Consider the following simplest case of client-server exchange. The client waits for a ready signal from the server, then sends a request and waits for a response.

Here is the code sample:

Its timing diagram:

And the legend:

Both the client and the server come out of reset and the server immediately asserts ready.
The client sees that the server is ready and immediately provides the input.
The server sees the input and immediately responds.
The client sees the response and immediately passes it on.

As you can see, despite all the reactions being immediate, the registers only pass the updated value signal at the next tick. Therefore, should you have inlined the calculation in the client, it would have been immediate, but when you delegate it to a different registered component, it takes 4 clock cycles.

Factoring a VHDL program into components should be based on physical composition, not on logical delegation.

Another thing, in software, the basic concept is that code is executed by a thread, a logical entity that follows the code like a vinyl player needle. And then we could start any number of threads playing the same record independently.

In hardware it is once again the opposite. Now it is the values that flow through the program, and it is the front of that wave that is its current state. You can't just run a second wave through the same wires, they will cancel each other. To increase parallelism in a registered circuit, we notice that every register holds the flow like a floodgate. Then it is possible to have multiple waves coming one after another, separated by as much as a single tick and they will not conflict.

Finally, from the most basic coding standpoint, registers are invisible. Just like the flow of time from the first part of this article, they do not appear in the code. And you just have to see them where they are supposed to be, to understand how the circuit behaves. I will address this in more details in the next part of this article:

Part 3: Code patterns and inferred behavior

Thank you for reading !

Learning FPGA programming, key points for a software developer (part 1, the time)

Dmitry Dvoinikov — Tue, 21 Jul 2020 11:27:47 +0000

It may be difficult for a software developer to pick up FPGA hardware programming. Here I explain a few important concepts that I wish someone had explained to me.

This post began my FPGA journey as an absolute beginner that I then was.

Several months later, a dozen books read, couple of very simple toy projects worked upon, a bunch of devices experimented with, I have better understanding of why it was so difficult, and would like to share the experience with you.

All of it may be in the books, but the books tend to either assume the electrical engineering background or stay clear off the hardware territory. Either way, it does not help a software developer. It was an occasional diagram here or a stray sentence there that lit the bulb for me. The few concepts I found most important and try to explain as clear as I can from a software developer's perspective.

There are three parts in this article. This first part is about the concept of time. The second part is about registered logic, and the third - code patterns and inferred behavior. A minimal VHDL knowledge is expected from the reader.

VHDL is not a regular (imperative) programming language. A program in VHDL is not a sequence of instructions to be executed by some underlying machine. VHDL program is a schematic of a circuit. Nothing moves there, nothing is "executed". Once VHDL program is compiled, the circuit is quite literally cast in copper, and then only electric current flows through the wires.

Let me repeat. There is nothing there but electric wires. The entire purpose of the circuit that you build is to transform input signals into output signals in a specific manner. So that the following VHDL fragment

c <= b;
d <= a;

compiles into

For this simple example it may look obvious, but here is another one, what do you think happens when you compile

c <= a * b;

This:

Number theory is well explored and the multiplication algorithms may be known, but the resulting circuit is still a twisted mile of wires. It is so complicated because from the assignment that we wrote it appears that we wanted the product output to appear on the wire at the same time as the inputs are set.

The biggest hurdle of hardware programming is time.

Time means very different thing in hardware, than it does in software. For a software developer writing a program, time flows from one line of code to the next, each line happening conceptually in a separate instant. We read it as "and then ...".

For example, as a software developer, what could you say about time in the following C-like code fragment ?

Most likely your intuition will tell you that instant 1 < instant 2 < instant 3 (execution order) and duration 1 ~ duration 2 < duration 3 (estimated complexity) and that's about as much as we typically care about time in software world.

In a regular program time flows down and the lines are executed in order. In VHDL the flow of time is orthogonal, it flows along the lines, while the lines themselves happen at the same time.

Let's look at the simplest VHDL fragment again:

When you realize that each assignment is a transmission of a signal over a wire, it becomes even more interesting.

First, it's not even an "assignment" in a variable sense, the outputs are not "assigned". They just repeat the input after a short delay. It makes no difference if it is a one, zero, or a sine wave:

Then there is an issue of "same time". It takes time for the signals to propagate through the wires and the propagation delays vary. Remember the multiplication mess ? If you look closely, it appears that the integers being multiplied are actually represented as one wire per bit, and different bits take different paths through the circuit:

Therefore, even if all the input bits were asserted at the same time, the output bits may get out at different times. The nanosecond difference may sound small, but it is real, it accumulates, and becomes crucial, when you realize that one circuit's output is another's input:

Then here is the critical question:

How does a circuit know when its inputs are ready ?

It doesn't. Depending on when and in which order the input signals arrive, the circuit's output will go through transitions, some of which are useless, and some could even be semantically impossible. The output of the second circuit will therefore be garbage, before the inputs have settled. It is only after the inputs are stable plus some internal delta, when a circuit's output makes sense.

You can combine any number of circuits by wiring them together (this is called combinatorial in VHDL), but you have to pay attention to the timings and signal propagation, to know which signal arrives to its destination when, and when the output actually becomes usable.

Time flow is therefore the most important part of VHDL program. It is not mentioned in the actual code for the most part, but you just have to see it there to be able to reason about the circuit's behavior.

Thank you for reading, and the next parts of this article discuss:

Part 2: Registered logic
Part 3: Code patterns and inferred behavior

Password keeping devices. Comparison of YubiKey vs. OnlyKey

Dmitry Dvoinikov — Tue, 28 May 2019 11:36:48 +0000

There’s just a couple of problems with passwords.

First, we need them to be strong. Some 12 random characters or more. No matter if you use a password manager, trust a small company to store all your passwords in a cloud, or a big corporation to track all your logins at all, you still need a master password, and it’d better be double strong now. You can use biometrics as an alternative to the master password on your laptop, but this effectively binds you to it.

Second, there still are cases when you absolutely have to type the password manually. Basically, everything outside of desktop. One such case is full disk encryption at boot loader prompt. Or a login on an important console. And this is exactly when you need the strongest passwords.

But can you remember a single truly strong password ? I can’t.

In this article I’m going to analyze and compare two hardware devices that remember your passwords and type them for you.

Specifically, YubiKey and OnlyKey.

YubiKey is a Xerox of authentication devices, their products come in all shapes and sizes, connectable via different ports, also with wireless support. From now on I will refer as just a YubiKey to the one device that I have, namely YubiKey Edge. It is a simple full size USB dongle, no NFC. OnlyKey is a new contender and they have just one product which is also a full size USB dongle.

I will also focus exclusively on using both in “first factor static password” mode. Despite both supporting multiple second factor modes, I’ve found it impractical to use them as a second factor. A smartphone or a dedicated $5 dongle is a better option for that.

That out of the way, let’s begin.

In concept, both devices are identical, and the idea behind them is beautiful in its simplicity. They are essentially external keyboards in a USB dongle form. You press a button on the dongle, it spits out the password as if someone typed it on a keyboard. That’s it.

Here they are side by side:

The elephant in the room is of course the number of buttons. YubiKey has one, OnlyKey has six. I will address it under Features.

First impression and ergonomics

Manufacturing quality is impeccable on both devices.

YubiKey feels more like a consumer utility, it is a perfectly rugged piece of plastic, something that you can forget in a pocket of your jeans being washed and it still works.

OnlyKey feels more like a serious security device, it is cut from a piece of PCB, you can see all the circuitry laminated in a transparent epoxy, and there is a separate rubber sleeve that you are supposed to put on after you have finished looking at it. It is also larger and thicker.

Buttons on both devices are not really buttons. They are copper plates that you touch, not push. No tactile feedback, but they last.

Features

YubiKey is extremely simple. It can store two passwords. Since there is only one button, you choose which password to type by touching the button momentarily or for longer than two seconds.

OnlyKey is way more complex. It has a large LED that changes color and blinks differently, depending on what the device does. It has six buttons and can store 24 passwords. Given six buttons and the same two-seconds trick as with YubiKey, you get 12 passwords. And there are two different user profiles, a total of 24.

But the crucial difference between the two is that OnlyKey is itself password protected. You need to punch in a correct PIN after plugging it. The LED goes green and the device is ready to use. This is a major security benefit. You can leave OnlyKey anywhere and not worry who touches it. YubiKey you need to keep an eye on at all times.

Another big plus for OnlyKey is that it is way more configurable. Each of 24 entries you can set up in such a manner that it types, for example, URL, ENTER, 3 seconds pause, username, TAB, password and finally ENTER. Not just password.

There are other OnlyKey features that indicate that its makers indeed wanted a security device, not a consumer utility. So for example you can set up a fake PIN which could be entered under duress upon which the device erases itself.

Usability in the field

YubiKey just works. It’s perfectly simple, not much else to say. You plug it in, it’s ready in three seconds, touch the button, and away it goes.

OnlyKey takes the same three seconds to boot, but then you also need to punch your PIN, which takes another four seconds, then another three seconds to decrypt before it goes green. It feels slow, but not terribly slow.

When you plug the OnlyKey to a side port of a laptop, the buttons on the OnlyKey are too close to the edge of the keyboard. It happens, although not very often, that I accidentally touch a button with the edge of a palm, and it types in the password unexpectedly. That’s a nuisance that can become a very serious security leak. You may need to be unplugging the device each time, or plugging it to a port not so easily accessible.

There is also an issue with the entire class of such devices, and it is that they send in not characters, but scan codes, meaning they imitate key presses at the keys located in certain positions of the keyboard. What's the difference ? When an international layout is activated, such as Russian or German, what you get in the password is the sequence of Cyrillic letters, or have some letters (Z vs. Y) swapped. This is especially annoying when you plug the device to a phone, it is recognized as an external keyboard and the on-screen keyboard disappears, making it impossible to switch the layout.

Configuration

Both devices are programmable each using a companion application. The applications do the job, but as far as usability goes are nothing but a column of checkboxes.

Platform compatibility

The inevitable question - is it possible to use such devices with different platforms ? Both devices that I have work perfectly with Windows and Linux, also at boot loader prompt. They also worked for me with Apple devices via a Lightning-to-USB adapter.

Mobile, it’s not rosy for YubiKey. YubiKey devices seem to only support second factor over NFC, not static password, and my Android smartphone does not recognize YubiKey as an external keyboard when plugged in. What it does recognize is OnlyKey, and it is absolutely usable with Android.

Conclusion

Both devices I could highly recommend. Appearance aside, here is the takeout:

YubiKey is better, because it’s easier to use. And the manufacturer provides different devices that might work in your case. It is worse, because it only remembers two passwords, and they are not secured by the device.
OnlyKey is better, because it remembers a lot of not just passwords but entire arbitrary login scenarios, and they are all stored securely. It is worse, because it is not quite as easy to use.

Thank you so much for reading !