On Thu, 03 May 2018 21:31:59 -0400, Michael wrote:
>
> I'm getting this message on both of my alphas...can anyone tell me
> what I'm doing wrong? I've double checked the PIN.... same one I use
> to log into the console
>
> Firmware tarball /usr/share/cryptech-alpha-firmware.tar.gz content:
> -rw-r--r-- root/root 5324179 2017-12-15 09:31:00 alpha_fmc.bit
> -rwxr-xr-x root/root 60644 2017-12-15 09:31:53 bootloader.bin
> -rwxr-xr-x root/root 1455424 2017-12-15 09:31:53 bootloader.elf
> -rwxr-xr-x root/root 494344 2017-12-15 09:31:55 hsm.bin
> -rwxr-xr-x root/root 2465640 2017-12-15 09:31:55 hsm.elf
> -rw-r--r-- root/root 2529 2017-12-14 17:32:43 tamper.hex
> -rw-r--r-- root/root 3340 2017-12-15 09:32:01 MANIFEST
> Uploading hsm.bin from /usr/share/cryptech-alpha-firmware.tar.gz
> Initializing management port and synchronizing with HSM, this may take
> a few seconds
> wheel PIN:
> Device does not seem to be ready for a file transfer (got
> '\r\n\r\nAccess denied\r\n\r\nUsername: ')
> Access denied
Make sure it's the right username ("wheel", not "user" or "so").
You may be running a version of the bootloader old enough that it
doesn't understand the current keystore format, and therefore gets
confused when looking up the PIN. If so, it will think there is no
PIN set and will therefore fall back to the compiled-in last gasp PIN,
an annoying string which you can find in the source.
If none of that works, you can re-flash via a programmer, or you can
try wiping the keystore to put it into a known state in which
everything will use the compiled-in last gasp PIN, then re-flash.
If you have keystore content you want to preserve across such an
operation, you can use cryptech_backup in "soft-backup" mode.
There's newer packaged firmware than the above on apt.cryptech.is if
you don't feel like building the current firmware yourself.
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
