Werner Almesberger | 20 May 19:44 2016
Picon
Gravatar

Anelok: the crypto reform (4/4), implementation and future

Middleware
----------

The middleware related to handling account databases covers three
areas:

- the actual cryptographic primitives,
- the code that reads or writes account records, and
- base32 encoding/decoding for when a human-readable representation
  of a key is needed.

There are two implementations of Anelok's cryptography, one in the
firmware and another for host tools. The firmware can only read the
account database so far, but not edit it. The host tools can read
and write.

The bits in the firmware:

- cryptographic primitives:

  TweetNaCl:
  https://gitlab.com/anelok/anelok/blob/master/crypter/tweetnacl.h
  https://gitlab.com/anelok/anelok/blob/master/crypter/tweetnacl.c
  from
  https://tweetnacl.cr.yp.to/
  included via
  https://gitlab.com/anelok/anelok/blob/master/fw/db/crypto/tweetnacl.c

  uNaCl (optimized elliptic curve multiplication):
  https://gitlab.com/anelok/anelok/tree/master/fw/db/crypto/unacl
(Continue reading)

Werner Almesberger | 20 May 18:19 2016
Picon
Gravatar

Anelok: the crypto reform (3/4), what all this looks like

Let's assume we have the following accounts:

Name:   Mail
URL:    foomail.com
Login:  me
PW:     Fohd3ien

Name:   SocNet
URL:    sidetome.com
Login:  goatee81
PW:     asdf

Someone who has access to the encrypted account database but doesn't
know the right keys would be able to see this:

% ./crypter.py default.bin
Length: 174 bytes
  PKw: HWUZ-CSHI-M4TV.ZTGX-7NCR-LMSR.QFCC-7N7A-BYN3.XSIH-DOQY-TFJ4.MN3A
  Nonce: N6TD-ZM6F-ASPY.G3I8-BFN8-XPII.JHH6-XMVG-JZLS.IIC
  Readers: 1
    PKr: HWUZ-CSHI-M4TV.ZTGX-7NCR-LMSR.QFCC-7N7A-BYN3.XSIH-DOQY-TFJ4.MN3A
    EKr: W9E7-A7LF-E6BZ.AQ3L-8VVQ-MRTA.G4SF-3JYW-ZXYE.LO3R-ARFT-DSWU.NFTB
  Payload: 53 bytes
    28 4A 9F 37 F0 2F 25 8B 59 25 DE 9A 96 D6 D3 3B  (J.7./%.Y%.....;
    DC 1E 01 EE 91 DD 97 AE 77 94 88 5B 43 3E FC B3  ........w..[C>..
    4E BA 39 27 A0 3E 11 7B 4F BF 88 00 9E 3A E4 4E  N.9'.>.{O....:.N
    1B 50 01 51 61                                   .P.Qa
Length: 179 bytes
  PKw: HWUZ-CSHI-M4TV.ZTGX-7NCR-LMSR.QFCC-7N7A-BYN3.XSIH-DOQY-TFJ4.MN3A
  Nonce: HFUI-AUGI-QWVJ.AAAU-DGQF-FKVU.HD9S-BXZ9-WSQN.OGA
(Continue reading)

Werner Almesberger | 20 May 17:15 2016
Picon
Gravatar

Anelok: the crypto reform (2/4), format and algorithm

The records in the account database have the following format:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-format-20160518.pdf
https://gitlab.com/anelok/anelok/blob/master/doc/crypto/format.fig

I also have a description in text form, along with the algorithm:
https://gitlab.com/anelok/anelok/blob/master/crypter/README

The main steps of encryption are:

1) We generate a nonce (N) and the random key (RK) used to encrypt the
   record content.

   N has to be unique per record encryption but doesn't have to be
   difficult to guess, while RK must be unguessable (for an outside
   party) and it must be unique at least per group of records with
   the same readership. In practice, this means that RK should be
   unique per record, but an existing RK could be reused if changing
   a record, as long as the readership remains the same.

2) For each reader, we perform the key agreement using Curve25519,
   obtaining a secret (ShK) shared between reader and write.

   This is the "beforenm" part of https://nacl.cr.yp.to/box.html

3) We encrypt RK with key ShK using crypto_stream_xsalsa20, yielding
   the encrypted key EKr. While there is only one RK per record,
   there is a different EKr for each reader allowed to decrypt the
   record.

   https://nacl.cr.yp.to/stream.html
(Continue reading)

Werner Almesberger | 20 May 15:48 2016
Picon
Gravatar

Anelok: the crypto reform (1/4), overview

So far, the account database format only supported one reader per
record and the tools for creating the database used only a single
key pair, which kinda defeats the purpose of public-key cryptography.

After some hands-on experience with NaCl
https://nacl.cr.yp.to/index.html
and studying Dan Bernstein's paper on how it all works under the hood
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf
I felt confident to take the next step and to implement multi-reader
encryption.

This required a change of the database format and the introduction of
encrypted per-record keys. You may remember this diagram
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-accreg-20150420.pdf
from these threads:
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010850.html
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010851.html
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010852.html
http://lists.en.qi-hardware.com/pipermail/discussion/2015-April/010854.html

The updated version is quite similar:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-accreg-20160520.pdf
https://gitlab.com/anelok/anelok/blob/master/doc/crypto/accrec.fig

The main changes are that I removed the key derivation function (KDF),
the initialization vector (IV) is now a nonce, and involving hashes
in the generation of random numbers is less encouraged than before.

The KDF simply wasn't necessary: the Curve25519 key agreement produces
a 32 byte key, which is exactly the size of the secret key for the
(Continue reading)

Paul Boddie | 17 May 20:29 2016
Picon

Anelok: The Yubico opportunity

Sorry to use the "Anelok:" prefix, Werner, but I don't want people complaining 
about the topic after opening the message. ;-)

Anyway, this story has been "trending" recently: Yubico has apparently gone 
completely closed on their latest product, as opposed to somewhat closed, 
meaning that the whole transparency argument has erupted around their 
token/key/credentials-management products...

"Yubico: Secure hardware vs. open source"

http://lwn.net/Articles/687676/

Indeed, the blog post that initiated the fuss is perhaps something worth 
mining for good discussion points...

https://www.yubico.com/2016/05/secure-hardware-vs-open-source/

It's interesting to read that they ditched the Java Card stuff in their latest 
product. I saw an interesting talk about writing applets for that platform and 
it was a rather informative and entertaining glimpse behind the curtain into a 
somewhat bizarre world:

https://www.youtube.com/watch?v=31D94QOo2gY

Maybe there's an opportunity to be had here with Anelok. Get yourself a Let's 
Encrypt certificate for anelok.com and maybe people can be sent in that 
direction for more details. ;-)

Paul

(Continue reading)

Wolfram Sang | 10 May 16:09 2016
Picon

KS7010 driver goes staging

Hi,

I wanted to let you know that I just sent a patch series to put the
KS7010 driver for the Spectec SDW-823 card to upstream staging. It
included also a round of cleanups and bugfixes. See here:

http://thread.gmane.org/gmane.linux.kernel.renesas-soc/3554

Since the base of the series comes from the Nanonote project, I thought
maybe some interested persons might be still around here? In any case,
thanks to all involved in this driver so far. Much appreciated!

Regards,

   Wolfram

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion <at> lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
Werner Almesberger | 12 Apr 14:42 2016
Picon
Gravatar

Anelok: battery contacts revisited

In http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011019.html
I calculated/guessed the length of the contacts (i.e., the distance
between rear and battery) as 2.04 mm for Keystone 5225 and 2.54 mm
for Keystone 5203.

With a nominal battery size of 43.9 mm (+/- 0.6 mm) this yields a
total length for battery with contacts of 48.48 mm.

I wrote "calculated/guessed" since the drawings of the contacts
don't indicate the position relative to the battery (or relative
to each other).

But I now found this information on in the catalog:
http://www.keyelco.com/userAssets/file/Keystone-CatalogM65.pdf
Catalog page 37, PDF page 43.

They suggest a spacing of 49.5 mm, about 1 mm + tolerance more than
what I had. If we assume a tolerance of 2 * 0.1 mm, the case will
thus have to grow to a total width of at least 53.7 mm.

Since I'll have to stretch it to at least 54.0 mm to accommodate
the mechanical buttons anyway, this fits quite nicely.

- Werner

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion <at> lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
Werner Almesberger | 28 Mar 00:47 2016
Picon
Gravatar

Anelok: keeping the time during battery swaps (2/2)

The timekeeping gets an unplanned second part, for a fifth variant.
Fifth time is lucky, right ? :-)

http://downloads.qi-hardware.com/people/werner/anelok/tmp/time-backup-20160328.pdf

All the circuits presented so far have the issue that a voltage
above Vcc is present at the MCU's GPIO(s) when Vc1 > Vcc. This
is outside the chip's specification and may or may not cause
trouble.

Joerg suggested another variant, on page 5: the diode is now at
the MCU and thus clamps Vadc to Vcc. A standard diode with Vf
around 0.3 V at 1 uA (e.g., Panasonic DA2J10100L) should work
nicely for this.

One issue with the circuit is that the leakage current of the
ADC pin flows through the 3.3 MOhm resistor, which may cause a
voltage offset that is as large as the whole measurement range.
The magnitude of the leakage should depend largely on the chip
temperature.

Joerg suggested an algorithm that may help there, too. To take
a sample of the unknown Vc1, we would do something like this:

static void pulse(float duty)
{
	output(1);
	sleep(INTERVAL * duty);
	output(0);
	sleep(INTERVAL * (1 - duty));
(Continue reading)

Werner Almesberger | 27 Mar 06:55 2016
Picon
Gravatar

Anelok: keeping the time during battery swaps

To be able to support time-based protocols like TOTP [1], Anelok
needs to be able to provide reasonably accurate time. The sMCU
has a real-time clock driven by a 32.768 kHz "watch" crystal.

The problem is that this clock won't run without power, e.g.,
during a battery change. While battery changes should be relatively
infrequent, having to set the clock each time would be at least
inconvenient.

So far, the plan was to add some generously-sized silo capacitors
to keep the sMCU powered and thus the real-time clock running
during battery removal.

When discussing power distribution in Anelok on #qi-hardware, Joerg
suggested a rather different approach: instead of trying to keep
the clock running, why don't we just save the time across battery
swaps ?

The MCU has a low-voltage warning interrupt that can be set to
kick in well before the system voltage would be too low for the
MCU to keep running.

Now, what do we set the time to after coming back up again ? We
could just make an educated guess of how many seconds a typical
battery swap would take, but that may be a bit too inaccurate.

But what if we measure the time during which Anelok was off ?
Joerg suggested to use a capacitor that slowly discharges through
a resistor for this. When the sMCU comes up again, it can measure
the remaining voltage and calculate the downtime.
(Continue reading)

Werner Almesberger | 27 Mar 04:10 2016
Picon
Gravatar

Anelok: battery contacts (2/2)

Battery contacts come in many styles and sizes. In order to get a
quick overview of which ones might actually fit, I made some rough
outline drawings of the ones available from Digi-Key:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/aaa-contacts.pdf

Each drawing shows two concentric circles, one for the nominal size
of the battery itself (it has a tolerance of +/- 0.5 mm) and one for
the "tube" the battery compartment forms.

The contacts are approximated with a rectangle and are shown roughly
where I'd expect them to be located relative to the battery. In some
cases, this is just a guess.

Contacts should be entirely within the "tube", except that they can
protrude on one side, where the face the PCB. Some contacts have
solder tabs that are not shown. They would be part of these allowed
protrusions.

So this leaves the following candidates that fit:

- Keystone 238 (+) and 204 (-/omni): snap-on, perfect fit.

- Keystone 1021-1 (-) and 1075-1 (+) would also fit, but the
  1075-1 seems be unsourceable.

- Keystone 5225 (+) and 5203 (-): slide-in. They appear to be
  slightly oversized, but the real parts have rounded corners and the
  diagonal is only about 10.6 mm, so they should actually fit in the
  11 mm tube.
(Continue reading)

Werner Almesberger | 27 Mar 04:00 2016
Picon
Gravatar

Anelok: battery contacts (1/2) (was Re: Anelok: current out of Vbat)

Bas Wijnen wrote:
> You have to design the case anyway.  I would expect that the case is the
> battery holder, so you only need to insert the contacts.

The tricky bit is finding suitable contacts. Well, since I hadn't
picked contacts just yet, I went on a search ...

I found five different types:

1) PCB-mounted, SMT. Alas, they all have the battery above the
   contact, not on the side. A side-facing contact would be very
   nice to have, also solving the issue of how the battery
   contacts connect to the PCB.

   For AAAA, this exists:
   http://www.battery-contacts.com/part.php?pn=BK-6113
   Alas, they're too small to even try with AAA.

2) PCB-mounted, through-hole. Some are fairly bulky and some seem
   to be just contacts used in battery holders with a plastic base,
   e.g.,

   Holder (1075):
   http://www.keyelco.com/product.cfm/product_id/14043

   Positive contact (1075-1):
   http://www.keyelco.com/product.cfm/product_id/14196

   Negative contact (1075-2):
   http://www.keyelco.com/product.cfm/product_id/14211
(Continue reading)


Gmane