cryptotronix / hashlet

Driver and application software for the Cryptotronix Hashlet

Cryptotronix Hashlet

Getting

The easiest way to install hashlet right now is to add my debian repository and then just:

sudo apt-get update
sudo apt-get install hashlet

However, I've only packaged the binary for ARMv7. If you want to help package a binary for another system, I'd appreciate the help!

The second easiest way to install the software is to download the latest release and then:

./configure && make
sudo make install

If you want to hack on hashlet, read more about building below.

Building

This project uses Autotools and you need that installed to configure and build the executable. I am mainly developing on a BeagleBone Black using Debian.

If you pull this repo (i.e. a non-release), you will need the following dependencies:

• autotools (i.e. automake, autconf, and libtool)
• Flex and Bison
• texinfo (for the documentation if you so desire)

The run time dependencies are:

• libgcrypt

Hardware

The hardware was available from Cryptotronix. We are an open hardware company, so see the hardware folder for the design to make this yourself. However, this software should work on any board that has an ATSHA204 in the I2C variety.

Running

see ./hashlet --help for full details. The default I2C bus is /dev/i2c-1 and this can be changed with the -b option. On some BBB, the bus is /dev/i2c-2. See this blog post for further details on BBB I2C.

Root

You'll need to run as root to access /dev/i2c* initially. You can change this by adding your user to the i2c group with:

sudo usermod -aG i2c user

Or:

sudo chmod o+rw /dev/i2c*

Currently supported commands:

state

./hashlet state
Factory

This is the first command you should run and verify it's in the Factory state. This provides the assurance that the device has not been tampered during transit.

personalize

./hashlet personalize

With the key import feature:

./hashlet personalize -f keys.txt

This is the second command you should run. On success it will not output anything. Random keys are loaded into the device and saved to ~/.hashlet as a backup. Don't lose that file. Keys from another hashlet can be imported with the -f option, where the file is not also named ~/.hashlet.

random

./hashlet random
62F95589AC76855A8F9204C9C6B8B85F06E6477D17C3888266AEE8E1CBD65319

This command also takes the -B parameter which allows you to specify the number of bytes you want back from the random number generator.

mac

./hashlet mac --file test.txt
mac       : C3466ABB8640B50938B260E17D86489D0EBB3F9C8009024683CB225FFFD3B4E4
challenge : 9F0751C90770E6B40E34BA8E06EFE453FAA46B5FB26925FFBD664FAF951D000A
meta      : 08000000000000000000000000

On success it will output three parameters:

1. mac: (aka challenge response) The result of the operation
2. challenge: This is the input to the Hashlet, after a SHA256 digest
3. meta: Meta data that must accompany the result

check-mac

./hashlet check-mac -r C3466ABB8640B50938B260E17D86489D0EBB3F9C8009024683CB225FFFD3B4E4 -c 9F0751C90770E6B40E34BA8E06EFE453FAA46B5FB26925FFBD664FAF951D000A -m 08000000000000000000000000

Checks the MAC that was produced by the Hashlet. On success, it will with an exit value of 0.

offline-verify

./hashlet offline-verify -c 322B3FFC3BE16B4CC5B445F8E666D0BA5C5E676D00FABD2308AD51243FA0B067 -r FB19B1C63161B6C34CA9D291D1CD16F98247BBA9A298775F795161BEB95BB6EF

On success, it will output an exit code of 0, otherwise it will fail. The point of this command is that a remote server can verify the MAC from the Hashlet without a device. The keys are written to ~/.hashlet upon personalization and if this file is store on the server, it can verify a MAC.

The workflow goes like this:

1. Mac some data to produce a challenge response.
2. Send the challenge and MAC to the remote server, which has the key store file.
3. Perform offline-verify on the remote server.

hmac

hashlet hmac -f ChangeLog
CD0765AB1F94698E0EACDE22C10F362E925F4F4017B75FDE5AB3124FCEBE9754

echo test | ./hashlet hmac
9CAF53A19F4A8D751F9D03ED3991EF648DC9246D2B329D9A650307212D994326

Performs HMAC-256. Your input data is combined with data on the device, so this isn't a pure HMAC-256. Your data will be applied to SHA-256 and then combined, per the datasheet, with device data. That result is fed into HMAC-256.

offline-hmac

hashlet offline-hmac -r CD0765AB1F94698E0EACDE22C10F362E925F4F4017B75FDE5AB3124FCEBE9754 -f ChangeLog
echo $?
0

echo test | ./hashlet offline-hmac -r 9CAF53A19F4A8D751F9D03ED3991EF648DC9246D2B329D9A650307212D994326
echo $?
0

Similar to offline-verify, verifies the hmac operation using the key file from ~/.hashlet.

serial-num

./hashlet serial-num
0123XXXXXXXXXXXXEE

X's indicate the unique serial number.

Options

Options are listed in the --help command, but a useful one, if there are issues, is the -v option. This will dump all the data that travels across the I2C bus with the device.

Design

In the hardware folder, one should find the design files for the Hashlet. The IC on the hashlet is the Atmel ATSHA204.

Support

IRC: Join the #cryptotronix channel on freenode.

Contributing

Pull requests welcome :)

hashlet's Issues

Update Documentation for version 1.0.0

Things that must be updated:

• Remove references to BeagleBone only, since the Pi is now supported
• Update schematic and board figures in document
• Update Github README
• Add nonce command
• Update commands to remove reference to /dev/i2c-x

Cleanup all debug statements to use log function.

Redirect all printf to CTX_LOG. All new debug statements should use this function.

Personalization reports failure but appears to succeed

Per the following log, personalization reported failure but appears to have succeeded.

~/code/c/hashlet
(0) <arm> $ sudo hashlet /dev/i2c-1 state                                         
Factory
~/code/c/hashlet
(0) <arm> $ sudo hashlet /dev/i2c-1 personalize
Failure
~/code/c/hashlet
(0) <arm> $ sudo hashlet /dev/i2c-1 state
Personalized
~/code/c/hashlet
(0) <arm> $ sudo ls -la /root/ | grep hash
-rw-r--r--  1 root root 1328 Jan 27 08:18 .hashlet

Refactor to use kernel module

On a branch, refactor to use kernel module, which will help in testing that module. Ultimately, this code needs to use the library as well.

Fix keys in slots 14 and 15

Slots 14 and 15 should have fixed keys. This will facilitate testing and the user will still have 14 key slots with which to play.

Config zone must be set to OTP zone of read only

The configuration zone defaults the OTP zone to consumption mode, which is not supported. It must be changed to read only mode.

ATSHA204 has low entropy on startup without seed update

The ATSHA204, not the ATSHA204A, has low entropy on device startup and will not produce random numbers without a seed update.

If you change this code and recompile the software, you will have poor random numbers. If you use the software as-is, which will update the seed on the device each time, you should be fine.

Atmel confirmed this behavior and the software, as implemented is using the manufacture recommend method.

This device works by using a seed -- if this bothers you, you are free to use a different random number generator. The major feature of this device is to securely store MAC keys anyway.

Regardless, for those who wish to use this device without a seed, there should be a warning message (with a user conformation) that allows them to use the device.

Alternatively, go get an ATSHA204A. This software will work with that device as well.

Set the OTP Zone

Program the One Time Programmable Zone with default configuration data.

Add ability to accept external info for Nonce

The nonce CLI interface should accept external data (20 bytes) or load nonces directly (32 bytes).

AM_PROG_CC_C_O required in configure.ac

Running autogen.sh (at least on the Raspberry Pi running Raspbian) yields the following warning:

Makefile.am:7: compiling src/command.c' in subdir requiresAM_PROG_CC_C_O' in `configure.ac'

The following commit might be helpful in fixing this:

NVIDIA/cbootimage@1457416

Merge get_random_bytes patch

Adds new command to get a specified number of bytes.

From a2feb6fef29c1602a35867a76559825071f20143 Mon Sep 17 00:00:00 2001
From: Dave Taht <[email protected]>
Date: Sun, 16 Feb 2014 05:40:10 +0000
Subject: [PATCH] Added get_random_bytes command

-B number of bytes to get

hashlet -B 64 random-bytes

---
 src/cli/cli_commands.c |   22 ++++++++++++++++++++++
 src/cli/cli_commands.h |   13 ++++++++++++-
 src/cli/main.c         |    5 +++++
 src/driver/command.c   |   40 ++++++++++++++++++++++++++++++++++++++++
 src/driver/command.h   |   10 ++++++++++
 src/driver/hashlet.h   |   12 +++++++++++-
 6 files changed, 100 insertions(+), 2 deletions(-)

diff --git a/src/cli/cli_commands.c b/src/cli/cli_commands.c
index c88550d..957f2fd 100644
--- a/src/cli/cli_commands.c
+++ b/src/cli/cli_commands.c
@@ -46,6 +46,7 @@ void set_defaults (struct arguments *args)
   args->input_file = NULL;
   args->update_seed = true;
   args->key_slot = 0;
+  args->bytes = 32;

   /* Default MAC mode */
   args->mac_mode.use_serial_num = false;
@@ -112,6 +113,7 @@ int add_command (const struct command cmd, int loc)
 void init_cli (struct arguments *args)
 {
   static const struct command random_cmd = {"random", cli_random };
+  static const struct command random_bytes_cmd = {"random-bytes", cli_random_bytes };
   static const struct command serial_cmd = {"serial-num", cli_get_serial_num };
   static const struct command state_cmd = {"state", cli_get_state };
   static const struct command config_cmd = {"get-config", cli_get_config_zone };
@@ -131,6 +133,7 @@ void init_cli (struct arguments *args)
   int x = 0;

   x = add_command (random_cmd, x);
+  x = add_command (random_bytes_cmd, x);
   x = add_command (serial_cmd, x);
   x = add_command (state_cmd, x);
   x = add_command (config_cmd, x);
@@ -277,6 +280,25 @@ int cli_random (int fd, struct arguments *args)
   return result;
 }

+int cli_random_bytes (int fd, struct arguments *args)
+{
+
+  struct octet_buffer response;
+  int result = HASHLET_COMMAND_FAIL;
+  assert (NULL != args);
+
+  printf("trying to get %d bytes\n", args->bytes);
+  response = get_random_bytes (fd, args->update_seed, args->bytes);
+  if (NULL != response.ptr)
+    {
+      output_hex (stdout, response);
+      free_octet_buffer (response);
+      result = HASHLET_COMMAND_SUCCESS;
+    }
+
+  return result;
+}
+
 int cli_get_serial_num (int fd, struct arguments *args)
 {
   struct octet_buffer response;
diff --git a/src/cli/cli_commands.h b/src/cli/cli_commands.h
index 3be0e92..a4aadee 100644
--- a/src/cli/cli_commands.h
+++ b/src/cli/cli_commands.h
@@ -48,6 +48,7 @@ struct arguments
   bool test;
   struct mac_mode_encoding mac_mode;
   uint8_t address;
+  int bytes;
   const char *challenge;
   const char *challenge_rsp;
   const char *meta;
@@ -86,7 +87,7 @@ int dispatch (const char *command, struct arguments *args);
  */
 void init_cli (struct arguments * args);

-#define NUM_CLI_COMMANDS 14
+#define NUM_CLI_COMMANDS 15

 /**
  * Gets random from the device
@@ -96,7 +97,17 @@ void init_cli (struct arguments * args);
  *
  * @return the exit code
  */
+
 int cli_random (int fd, struct arguments *args);
+/**
+ * Gets random from the device
+ *
+ * @param fd The open file descriptor
+ * @param args The argument structure
+ *
+ * @return the exit code
+ */
+int cli_random_bytes (int fd, struct arguments *args);

 /**
  * Retrieves the device's serial number
diff --git a/src/cli/main.c b/src/cli/main.c
index f8f5400..2c2b5b3 100644
--- a/src/cli/main.c
+++ b/src/cli/main.c
@@ -48,6 +48,7 @@ static char doc[] =
   "                  Hashlet.  It will load your keys and save them to\n"
   "                  ~/.hashlet as a backup\n"
   "random        --  Retrieves 32 bytes of random data from the device.\n"
+  "random-bytes  --  Retrieves X bytes of random data from the device.\n"
   "serial-num    --  Retrieves the device's serial number.\n"
 #if HAVE_GCRYPT_H
   "mac           --  Calculates a SHA-256 digest of your input data and then\n"
@@ -98,6 +99,7 @@ static struct argp_option options[] = {
   {"quiet",    'q', 0,      0,  "Don't produce any output" },
   {"silent",   's', 0,      OPTION_ALIAS },
   {"bus",      'b', "BUS",  0,  "I2C bus: defaults to /dev/i2c-1"},
+  {"Bytes",      'B', "Bytes",  0,  "number of bytes to return"},
   {"address",  'a', "ADDRESS",      0,  "i2c address for the device (in hex)"},
   {"file",     'f', "FILE",         0,  "Read from FILE vs. stdin"},
   { 0, 0, 0, 0, "Key related command options:", 3},
@@ -141,6 +143,9 @@ parse_opt (int key, char *arg, struct argp_state *state)
     case 'b':
       arguments->bus = arg;
       break;
+    case 'B':
+      arguments->bytes = atoi(arg);
+      break;
     case 'q': case 's':
       arguments->silent = 1;
       break;
diff --git a/src/driver/command.c b/src/driver/command.c
index 56a6c41..eb069e9 100644
--- a/src/driver/command.c
+++ b/src/driver/command.c
@@ -214,6 +214,46 @@ struct octet_buffer get_random (int fd, bool update_seed)

 }

+struct octet_buffer get_random_bytes (int fd, bool update_seed, int bytes)
+{
+  uint8_t *random = NULL;
+  uint8_t param2[2] = {0};
+  uint8_t param1 = update_seed ? 0 : 1;
+  int i = 0;
+  int rc = 0;
+
+  struct octet_buffer buf = {};
+
+  random = malloc_wipe (bytes + RANDOM_RSP_LENGTH);
+
+  struct Command_ATSHA204 c = make_command ();
+
+  set_opcode (&c, COMMAND_RANDOM);
+  set_param1 (&c, param1);
+  set_param2 (&c, param2);
+  set_data (&c, NULL, 0);
+  set_execution_time (&c, 0, RANDOM_AVG_EXEC);
+
+  
+  while (RSP_SUCCESS == (rc = process_command (fd, &c, &random[i], RANDOM_RSP_LENGTH))) {
+   i += RANDOM_RSP_LENGTH;
+   if( i - (RANDOM_RSP_LENGTH-1) > bytes) break;
+   update_seed = 0; /* No need to keep updating */
+   }
+
+  if (rc == RSP_SUCCESS) 
+    {
+      buf.ptr = random;
+      buf.len = bytes + RANDOM_RSP_LENGTH;
+    }
+  else
+    CTX_LOG (DEBUG, "Random bytes command failed");
+
+  return buf;
+
+
+}
+
 uint8_t set_zone_bits (enum DATA_ZONE zone)
 {
   uint8_t z;
diff --git a/src/driver/command.h b/src/driver/command.h
index c317a8b..4115643 100644
--- a/src/driver/command.h
+++ b/src/driver/command.h
@@ -88,6 +88,16 @@ enum STATUS_RESPONSE get_status_response (const uint8_t *rsp);
  * @return A malloc'ed buffer with random data.
  */
 struct octet_buffer get_random (int fd, bool update_seed);
+/**
+ * Get X bytes of random data from the device
+ *
+ * @param fd The open file descriptor
+ * @param update_seed True updates the seed.  Do this sparingly.
+ * @param bytes number of bytes to return
+ *
+ * @return A malloc'ed buffer with random data.
+ */
+struct octet_buffer get_random_bytes(int fd, bool update_seed, int bytes);

 /**
  * Read four bytes from the device.
diff --git a/src/driver/hashlet.h b/src/driver/hashlet.h
index 7833ad0..22fb4c8 100644
--- a/src/driver/hashlet.h
+++ b/src/driver/hashlet.h
@@ -47,7 +47,6 @@ void hashlet_teardown(int fd);
 void set_log_level(enum LOG_LEVEL lvl);

 /* COMMANDS */
-
 /**
  * Get 32 bytes of random data from the device
  *
@@ -57,4 +56,15 @@ void set_log_level(enum LOG_LEVEL lvl);
  * @return A malloc'ed buffer with random data.
  */
 struct octet_buffer get_random(int fd, bool update_seed);
+/**
+ * Get X bytes of random data from the device
+ *
+ * @param fd The open file descriptor
+ * @param update_seed True updates the seed.  Do this sparingly.
+ * @param bytes number of bytes to return
+ *
+ * @return A malloc'ed buffer with random data.
+ */
+struct octet_buffer get_random_bytes(int fd, bool update_seed, int bytes);
 #endif
+
-- 
1.7.10.4

Run code against a static analysis tool

The code needs to be checked against a static analysis tool. Coverity has a nice online checker for open source projects as does SCITools Understand. I've been playing too much "offense" getting features working that I'll have to spend some time cleaning up the issues.

check-mac command missing from help documentation.

Create initial documentation

Documentation is a priority. Before the next version, a minimal valuable documentation must be available. The draft is currently in the doc folder.

Fix i2c polling

In command_adaptation.c, read_and_validate, the logic polls for the response from the device, which is fine. But it uses a GOTO hack and it should be a loop with a limited amount of retries.

Alternatively, read_and_validate could not loop and the looping done here. The data sheet says one should poll for the expected execution time, so I'm leaning towards this solution.

Add option to NOT write keys to file

In the case that someone does not want to know the keys on the device, a command line option should be made available to NOT write the data to disk.

get_config_zone (int fd)

Now ,I have a question about get_config_zone() function, In this function body ,there is a "make_buffer (SIZE_OF_CONFIG_ZONE)" call , But , I can't find out where make_buffer(SIZE_OF_CONFIG_ZONE) is free ????

missing function under CentOS 6.5 (current)

gcc -DHAVE_CONFIG_H -I. -Wall -Werror -g -O2 -MT src/hashlet-test.o -MD -MP -MF src/.deps/hashlet-test.Tpo -c -o src/hashlet-test.o test -f 'src/test.c' || echo './'src/test.c
src/test.c: In function 'perform_hash':
src/test.c:107: error: 'gnutls_hash_hd_t' undeclared (first use in this function)
src/test.c:107: error: (Each undeclared identifier is reported only once
src/test.c:107: error: for each function it appears in.)
src/test.c:107: error: expected ';' before 'dig'
cc1: warnings being treated as errors
src/test.c:108: error: implicit declaration of function 'gnutls_hash_init'
src/test.c:108: error: 'dig' undeclared (first use in this function)
src/test.c:109: error: implicit declaration of function 'gnutls_hash'
src/test.c:111: error: implicit declaration of function 'gnutls_hash_get_len'
src/test.c:113: error: implicit declaration of function 'gnutls_hash_deinit'
make[2]: *** [src/hashlet-test.o] Error 1
make[2]: Leaving directory /home/herrold/rpmbuild/BUILD/hashlet-20131222' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/herrold/rpmbuild/BUILD/hashlet-20131222'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.lT0UE6 (%build)

possible additional option: -i (input file)

modeled on:
-o, --output=FILE Output to FILE instead of standard output

but of course
-i, --input=FILE Input from FILE instead of standard input

./configure calling for a missing option?

• /bin/chmod -Rf a+rX,u+w,g-w,o-w .
• '[' -x autogen.sh ']'
• ./autogen.sh
  configure.ac:7: installing ./compile' configure.ac:3: installing./install-sh'
  configure.ac:3: installing ./missing' Makefile.am: installing./depcomp'
• '[' -e configure ']'
• ./configure --enable-simulator --prefix=/usr
  configure: WARNING: unrecognized options: --enable-simulator
  checking for a BSD-compatible install... /usr/bin/install -c

/dev/i2c-1 is implied, make it an option

Requiring the bus is a bit redundant because the hardware is designed to use that bus. The software should make this an option, not a required argument.

hashlet 1.1.0: issueon src/parser/hashlet_bison.y

Hello,

After trying to add hashlet to a Yocto build, I found this :

`/home////build/tmp/work/cortexa9t2hf-neon-see-linux-gnueabi/hashlet/1.1.0-r0/build/../git/src/parser/hashlet_bison.y:40.12-21: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
40 | %type KEY_NUMBER
| ^~~~~~~~~~

/home////build/tmp/work/cortexa9t2hf-neon-see-linux-gnueabi/hashlet/1.1.0-r0/build/../git/src/parser/hashlet_bison.y:41.12-14: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
41 | %type HEX
| ^~~
`

It seems to be linked to the recent version of bison, which raises a warning when those lines are encountered. (https://savannah.gnu.org/forum/forum.php?forum_id=9639)[See 3.5]

After searching, I found this : (https://www.gnu.org/software/bison/manual/html_node/Type-Decl.html)[Type-Decl]; I used this to replace %type declarations with %nterm, but It seems that the build system is expecting us to be compatible with Yacc.

Do you have any idea how to fix this bison issue ?

Set aside two key slots that are always available to write but not read

Allow users to store keys in two slots designate as write always, read never. This will essentially allow user programmable keys.

Suggested by chaincrusher on IRC.

Allow for settable I2C address

Expose an API to set the I2C address of the device during personalization. This will allow two hashlets to be on the same I2C bus in the case one is used as a removable token.

Add import key feature

If a Hashlet is "cloned", meaning that the same keys are on a different device, there is no need to keep the key store. Both hashlets can verify themselves.

Create man page

Debian packages should have a man page. Create one for the Debian release.

Add test framework

Now that some of the commands are working, a test framework needs to be added. This should be with autotools make check. The script should run some commands (NOT PERSONALIZE) and test their output.

It's a little tricky because the responses will come out different for each device.

Alternatively, another application can be developed that calls into the code to test certain features. The script would be easier.

Random command modification

Per the Atmel ATSHA204 datasheet, page 59, updating the random seed "prior to random number generation" is "recommended for highest security."

Configuration Zone Write

Hey there!

I have started using hashlet to configure and use an ATSHA294 device. I was wondering if personalize command allows you to write the Configuration Zone bytes.

Thanks

Fix 0.1.0 Documentation

first and foremost:

add a 'warning' indication to each caommand capable of
permanently 'locking' the device into a non-factory fresh
state

technical

1 section 2.2

in addition to the full key, you might point out the
'fingerprint' part, and matching email at the keyservers --
some (most, whom follow the subject of GnuPG keys casually)
prolly will not 'see' it

2 Get Key signed

1. section 2.2 typo

   s/fist/first/
   

2. caption 2.1 typo

   ibgcrypt vs [l]ibgcrypt
   

---

general

Appendix B is the typical fat boiler plate -- perhaps decrease
its font size as there is nothing new there

err at cross-compiling

While I'm doing
$ ./configure --target=arm-linux-gnueabihf --host=arm-linux-gnueabihf
I endup with error

 ----------------------------------------------------
   Unable to find gcrypt.h on this system.
   libgcrypt (libgcrypt11-dev) is required, please install
   and rebuild.
   ----------------------------------------------------

however, libgcrypt is installed, and without target / host errorless configure & make.
How to solve this problem ?

Compile warnings

"make -s" of 13dac38 "slowly cleaning up debug." yields:

In file included from src/command.c:21:0:
src/command.h:236:8: warning: parameter names (without types) in function declaration [enabled by default]

src/crc.c: In function ‘is_crc_16_valid’:
src/crc.c:130:3: warning: passing argument 2 of ‘print_hex_string’ from incompatible pointer type [enabled by default]
src/util.h:27:6: note: expected ‘uint8_t *’ but argument is of type ‘uint16_t *’

In file included from src/test.c:37:0:
src/command.h:236:8: warning: parameter names (without types) in function declaration [enabled by default]

src/test.c: In function ‘main’:
src/test.c:135:21: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]

In file included from src/command_adaptation.h:26:0,
from src/command_adaptation.c:21:
src/command.h:236:8: warning: parameter names (without types) in function declaration [enabled by default]
src/command_adaptation.c: In function ‘read_and_validate’:
src/command_adaptation.c:147:7: warning: assignment makes pointer from integer without a cast [enabled by default]

Add nonce ability

MACs and nonces are like PB&J. The ATSHA204 supports a nonce command, but it may be good enough to collect the random and mix the nonce in the hash prior to sending the command. As long as a nonce can be added.

Fix README.md

There are some errors on the README.md as it's no longer in beta, etc... that need be fixed.

Create offline HMAC command to generate a HMAC to be later verified with a hashlet

Build command-line monolithic interface

The ideal interface would be a kernel module for the i2c and command adaptation layer. However, that will not happen for the first release.

The beta release should be a monolithic command-line application that accepts the commands as arguments with sub-arguments.

Is there a bug in bool is_locked (int fd, enum DATA_ZONE zone) fucntion

hi jbdatko:

maybe sentence : if (read4 (fd, CONFIG_ZONE, config_addr, &buf)) did'nt handle the case that read4() execution false, if read4() return false, however is_locked() return result still is true!!!! Am right?

bool is_locked (int fd, enum DATA_ZONE zone)
{
uint32_t buf = 0;
const uint8_t config_addr = 0x15;
uint8_t *ptr = (uint8_t *)&buf;
const uint8_t UNLOCKED = 0x55;
bool result = true;
const unsigned int CONFIG_ZONE_OFFSET = 3;
const unsigned int DATA_ZONE_OFFSET = 2;
unsigned int offset = 0;

switch (zone)
{
case CONFIG_ZONE:
offset = CONFIG_ZONE_OFFSET;
break;
case DATA_ZONE:
case OTP_ZONE:
offset = DATA_ZONE_OFFSET;
break;
default:
assert (false);
}

if (read4 (fd, CONFIG_ZONE, config_addr, &buf))
{
ptr = ptr + offset;
if (UNLOCKED == *ptr)
result = false;
else
result = true;
}

return result;
}

Config zone not set properly

The config zone is not set properly. Keys can be read and written to after the data zone is locked, which is obviously not the intention.

Personalize may need to be run twice

The personalize command may need to be run twice to personalize the device. In this case, a write failed (required a resync) and the code mis-classified it. I'll have to refactor it and think about how to handle this on a general case.

However, it does appear safe to personalize the device.

debian@arm:~/repos/hashlet$ ./hashlet /dev/i2c-1 personalize -v
Device is awake.
crc : 0x33 0x43
Calculated crc : 0x33 0x43
*** Printing Command ***
Command: 0x03
Count: 0x07
OpCode: 0x02
Command Read
param1: 0x00
param2: 0x15 0x00
CRC: 0x00 0x00
Wait time: 0 seconds 1000000 nanoseconds
Total len: 8, count: 7, CRC_LEN: 5, CRC_OFFSET: 6

Sending : 0x03 0x07 0x02 0x00 0x15 0x00 0x17 0x5D
Received RSP : 0x07 0x00 0x00 0x55 0x55 0xF5 0x52
crc : 0xF5 0x52
Calculated crc : 0xF5 0x52
Response Success
*** Printing Command ***
Command: 0x03
Count: 0x07
OpCode: 0x02
Command Read
param1: 0x00
param2: 0x15 0x00
CRC: 0x00 0x00
Wait time: 0 seconds 1000000 nanoseconds
Total len: 8, count: 7, CRC_LEN: 5, CRC_OFFSET: 6


<snip>


*** Printing Command ***
Command: 0x03
Count: 0x27
OpCode: 0x12
Command Write
param1: 0x82
param2: 0x50 0x00
Data : 0xC3 0x19 0xA4 0xEF 0xB9 0xBF 0xBE 0x7B 0xA4 0x71 0xCD 0x63 0x14 0x07 0x43 0xCD 0xB6 0xD8 0xFE 0x94 0x4A 0xA1 0x9C 0x30 0xF5 0x07 0xA8 0xF6 0xDF 0x3C 0xDB 0xC5
CRC: 0x00 0x00
Wait time: 0 seconds 4000000 nanoseconds
Total len: 40, count: 39, CRC_LEN: 37, CRC_OFFSET: 38

Sending : 0x03 0x27 0x12 0x82 0x50 0x00 0xC3 0x19 0xA4 0xEF 0xB9 0xBF 0xBE 0x7B 0xA4 0x71 0xCD 0x63 0x14 0x07 0x43 0xCD 0xB6 0xD8 0xFE 0x94 0x4A 0xA1 0x9C 0x30 0xF5 0x07 0xA8 0xF6 0xDF 0x3C 0xDB 0xC5 0xCA 0x90
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Read failed, retrying
Received RSP : 0x04 0x11 0x33 0x43
crc : 0x33 0x43
Calculated crc : 0x33 0x43
Response Success
Failure

Implement HMAC command

Add CLI and Driver code for the HMAC command.

hmac missing from usage

The hmac command is in the README.md, but missing from the --help output.

Add feature to import random from Hashlet into kernel

Until the hashlet is a char device, it is a little kludgy to use as the kernel's entropy source. There is an ioctl call that will add entropy from user space (as a privileged user) and update the available entropy.

Implement MAC and CHECKMAC

For the beta release, the device should be able to perform a MAC (without a Nonce) and successfully report the MAC is correct.