Werner Almesberger | 19 Apr 16:10 2015
Picon

Anelok: first try at crypto: for further study (4/3)

My last few mails may have made the topic of cryptography in Anelok
look trivial and boring. But don't worry, there is more:

- structuring of information: I already mentioned one aspect in the 
  second mail: there may be one block of key data for each account 
  record or multiple records could share a block. What makes the most
  sense ?

  There are also other issues, like how we represent directories and
  different access levels.

- what part of the account information should be  encrypted and what
  not ? Encrypting everything may be the safest choice, but are there
  major drawbacks ? Does computational overhead go through the roof ?

- management of the list of authorized readers and writers. How does
  a device learn about changes in the list ? How are the changes
  validated ? And how many such lists are there anyway - just one per 
  user (shared and synchronized among all the user's devices) or
  multiple ?

- what algorithms to use ? I'm pretty much set on Curve25519 [1] for
  ECDH, but what for symmetric encryption, what for hashing, what
  key derivation function ? We'd also want algorithms that are
  reasonably compatible in what data they expect and produce, and
  how they stretch or lose entropy.

- last but not least, what implementations ? There are quite a lot of
  implementations for ECDH alone [2, 3, 4, 5, 6, 7] (and that's just
  the smaller packages) and there are more when we consider ECDSA as
(Continue reading)

Mark Tuson | 19 Apr 11:24 2015
Picon

Why I joined: the NanoNote

Hello.

I've been a member of this list for something like five years; I joined 
following my purchase of a Ben NanoNote, thinking it might he useful to 
be a member of the community. Help and be helped, and all that.

There was supposed to be a successor to the Ben about three years ago, 
and there wasn't. In fact, the second successor should have been 
released last year, and it wasn't.

So, I ask, was the whole NanoNote thing a flash-in-the-pan episode of 
wishful thinking? Or was it a real project that simply fizzled out? Last 
time I asked about it I was told something like 'they tried and you're 
evil for not appreciating the effort that's gone into this,' but that's 
not really a helpful answer. What actually happened? Is there a point in 
me still waiting on this mailing list to see if anyone's going to pull 
their finger out and make the damned thing, or what?

The actual reason why I'm writing to you like this is that since the 
project fizzled out to nothing, I've been a member of this list, waiting 
to see what was going to happen, and in the meantime I've been 
constantly bombarded with emails from the list, talking about projects I 
don't care two sugarlumps about.

Eagerly awaiting a real response.

Mark Tuson, BSc.

Werner Almesberger | 19 Apr 06:19 2015
Picon

Anelok: first try at crypto: randomness (3/3)

Now we get to the fun part: randomness.

Entropy users
-------------

An obvious place where Anelok requires randomness is for the generation
of record keys.

We may also want to provide an initialization vector (IV [1]) for the
payload encryption, but I haven't worked out an attack scenario yet
where not having an IV would significantly help the attacker to
accomplish anything meaningful. Suggestions ?

Note that the IV doesn't necessarily require randomness. Maybe we could
generate it deterministically from, say, the encrypted keys. This may
be somewhat similar to what NaCl's crypto_box [2] does with the help of
a nonce [3] (haven't looked at the details yet).

Last but not least, public keys used by devices (i.e., readers and
writers) require an excellent entropy source.

Anelok also needs random numbers for a few other things, but these are
not directly related to the encryption of account records.

Random number generation
------------------------

The problem with randomness is that it is an expensive good, especially
in small embedded systems like Anelok. And it is also a fragile thing.
Therefore, we should try to use randomness as sparingly and efficiently
(Continue reading)

Werner Almesberger | 19 Apr 00:40 2015
Picon

Anelok: first try at crypto: something-nymity (2/3)

Sometimes, one may want a bit more privacy. Let's see what options we
have for this.

Pseudonymity
------------

One possible feature that occurred to me is to hide the information of
who has written a record from anyone who is not an authorized reader.
This could be accomplished by introducing an "author" who is the real
source of the information in the record, and letting the "writer" just
be a pseudonym.

This pseudonym could be a completely random private key (*) used only
once, or anything more durable than that.

(*) For Curve25519, all it takes to build a valid private key from a
    random bit string is to clear or set five bits at fixed locations.
    ("Computing secret keys" in [1].)

The only changes needed in the system would be:

- we replace the checksum with a cryptographic signature [2, 3], which
  certifies that the writer did indeed what the author intended it to
  do,

- for identification, include the author's public key in the encrypted
  record,

- make the reader look up the author's public key in the list of
  authorized writers and validate the signed hash after decrypting.
(Continue reading)

Werner Almesberger | 18 Apr 17:56 2015
Picon

Anelok: first try at crypto: overview (1/3)

I thought a bit more about the details of encrypting the account
database. This is a first attempt at defining the general structure of
the cryptosystem:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/crypto-accreg-20150418.pdf

Some optional features are drawn in grey. I'll discuss them towards
the end of this mail. The whole drawing is a little complex, sorry
about that. For a more gentle introduction, I'll have to break it down
into smaller pieces.

What this shows is the process of encrypting and decrypting a record
of the account database. The record would contain the password and may
contain other things, e.g., the name of the account record (e.g., "My
server"), maybe some URL or address, a user or login name, etc.

This information is encrypted such that all the authorized readers
(i.e., Anelok devices and any other trusted systems) can read it. For
simplicity, I assume for now that we have a trusted source for the
public keys of the authorized readers (and only of readers who are
authorized). This source is shown as the "Authorized" box.

Writing
-------

When creating a new account record or when editing an existing record,
the writer first prepares the record's content ("Plaintext"), adds a
checksum ("MIC", Message Integrity Code), then generates a key
("Record key") and uses this key to encrypt plaintext and checksum
with the symmetric cipher "Esym."
(Continue reading)

Werner Almesberger | 9 Apr 07:49 2015
Picon

Anelok: the power struggle

Some news regarding Anelok's struggle for power:

Days on battery
---------------

First the best of the bunch: I had a device run exclusively on battery
power. The battery, a fresh CR2032 cell, lasted for several days of
standby and occasional use, I think something like four or five days.

This may not sound like much, but it's definitely a step up from the
previous battery run that ended after a minute or so with the system
collapsing.

Standby current of the system is still fairly high - some two orders
of magnitude above the ~6 uA I measured as the absolute minimum I
could get.

I'm not sure how deeply the battery was discharged by this. I'm
currently draining it through an 15 kOhm resistor and the curves so
far suggest that Anelok was able to use about 30% of its charge before
things became unstable.

Since the killing blow probably came from some current spike, I
should be able to improve this ratio by adding a capacitor across the
battery.

Power tree
----------

I drew the power tree and it shows some good and some not so good
(Continue reading)

Paul Boddie | 5 Apr 19:08 2015
Picon

jz4730 Kernel Support

Hello,

Some of you may have spotted me on IRC a few days ago asking about the 
mainline kernel and support for the jz4730, as opposed to the jz4720 and 
jz4740 that are already supported and whose support is working (with some 
extra patches) for the Ben NanoNote.

Since asking for general advice, I've put together some patches that compile 
but don't actually get the jz4730-based device to boot, and I posted them to 
the mailing list related to that device:

http://lists.goldelico.com/pipermail/lenny400/2015-April/000041.html

The start of the thread is here, with some more description about what I did 
and the possible differences between the jz4730 and jz4740:

http://lists.goldelico.com/pipermail/lenny400/2015-April/000038.html

At the moment, I'm really looking for advice about things I might have done 
wrong or have forgotten to do, more technical than procedural. I don't write 
Linux kernel stuff normally, having only dabbled with some drivers a few years 
ago, so whilst things like coding style, not using the "right" git command to 
output diffs, failure to know Linus Torvalds' shirt size, and so on, are all 
useful to remedy in the longer term, I'd be more interested in people pointing 
out that I forgot to initialise something vital that might make a visible 
difference in the shorter term.

Anyway, I hope the somewhat diminishing enthusiasm of someone willing to look 
at Linux on the jz47xx series is encouraging enough for someone reading this 
to take a look!
(Continue reading)

Werner Almesberger | 3 Apr 21:41 2015
Picon

Anelok: migration to GitLab

Okay, I've reached a decision: Anelok's new home shall be GitLab.
What finally convinced me is that the bearded veterans of Devuan
use it, too.

The migration was fairly painless, despite both Gitorious and my
Internet access acting up badly in the last days.

Some changes:

- please be aware of some differences in terminology, especially
  of the word "project":

  GitLab	Gitoritous	GitHub		What it is
  -------------	---------------	---------------	--------------------
  project	repository	repository	One git repo (*)
  group		project		organization	A bunch of git repos

  (*) Or two repos, if we consider a Wiki associated with the main
      repo.

  I think I'll just use "repo" and "group". That way it's unambiguous.

- in Gitorious, the Wiki was at the group ("project") level (i.e.,
  anelok/). In GitLab, it moved to the repo ("project") level
  (anelok/anelok).

  Seem that we just have to live with this:
  http://feedback.gitlab.com/forums/176466-general/suggestions/3959212-allow-wiki-for-groups

- the Wiki is no longer publicly writeable. If I understand the
(Continue reading)

Werner Almesberger | 30 Mar 22:44 2015
Picon

Anelok: UI walk-through, authentication idea, better timing, power-saving

Assorted updates:

I made a first attempt at implementing the account display. It doesn't
look particularly pretty yet but it's a start. Here is a walk-through
of Anelok's current menu hierarchy:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/walkthrough.png

We start with a dark screen. Pressing "middle" brings up the logo and
releasing the sensor again leads us to the login screen. As long as
there is no input, the "setup" icon is shown. Pressing "top" leads to
the login-setup menu, which contains left/right switching, the
firmware build version, the device ID, the status of the radio chip,
and a few more technical items. (Note: all this is from the simulator.
IDs are different on the real device.)

Entering the correct pattern at the login screen leads to the account
selection list. Once more, there is a setup option, which at the
moment leads to a dummy menu. Try to select anything, and out comes
the apologetic ghost. That ghost also appears at many more places
where the respective next screen hasn't been implemented yet.

Selecting an account shows more detailed information: the account
name, a URL (or similar), the user/login name, and the password. Right
now, all this is pretty uniform but there could of course be more
customization.

I show two example accounts, a quite generic account ("Mail"), and one
where the password isn't shown ("e-Bank"). When scrolling down to the
password and pressing "middle" (see the eye icon), the password is
(Continue reading)

Werner Almesberger | 29 Mar 17:13 2015
Picon

Anelok: revisiting the migration from gitorious

I'm still trying to make up my mind whether Anelok's new home shall
be GitHub or GitLab. I looked for side-by-side comparisons, and they
all suggest that there's virtually no difference in terms of
functionality.

Those who chose GitLab over GitHub usually did so because they needed
private (i.e., without public access) repos and GitHub (where you have
to pay for any private repos) was getting too expensive.

Virtually all who mention GitLab are running a local version, be it
for the cost issue or be it just because they don't want to depend on
a third party for the service.

Examples:

http://www.quora.com/How-much-of-threat-is-Gitlab-to-GitHub-Enterprise
http://www.quora.com/What-are-some-major-differences-between-GitHub-and-GitLab-when-comparing-each-others-features-for-private-repositories
http://thenextweb.com/apps/2011/10/13/ship-it-faster-and-cheaper-gitlab-is-github-for-your-own-servers/

Those who chose GitHub over GitLab usually did so because they found
that running their local installation and keeping up with the
frequent updates was too much of an effort.

Example:

http://www.boxuk.com/blog/a-tale-of-three-git-systems/

For Anelok, running a local copy is not on the radar at the moment.
Instead, a reliable - both in terms of day to day operation as in
the longer-term viability - "cloud" service is important.
(Continue reading)

Werner Almesberger | 28 Mar 04:40 2015
Picon

Anelok: energy efficiency, second steps

This time I tackled the wasteful touch sensor:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/current-reduction-2.png

"display off in ui_off" is where we left off the last time, with an
average standby current of about 6.7 mA.

"use msleep also in init_cal" eliminates the last bastion of mdelay,
the touch sensor calibration. Anelok now takes little naps between
samples.

So far, so good, but it still busy-waits while the touch sensor
controller is sampling. So this was next. This involved a bit of
infrastructure work, e.g., teaching the firmware how to handle
interrupts (unexpectedly painless), and deepening my understanding of
how wakeups from a deep sleep are handled in this processor (that took
a while. See fw/plat/sleep.c for details.)

"deep-sleep while waiting for TSI" shows the result of all this: the
MCU now spends most of its time in deep sleep while in standby.
Standby current is down to 0.9 mA, most of which should now be the
boost converter.

One unexpected side-effect of all this is that the calibration seems
to take about twice as long as before. Not sure why. Deep sleep itself
should only add about 1 ms to the whole process, but this difference
is much longer. To be investigated later.

- Werner

(Continue reading)


Gmane