[s 3] Few steps to increase security of the baker account without a ledger nano

Here there are 3 independent steps that can be applied to keep the baking account (see page [s-1]) a bit more safe. The 3-accounts scheme described on page [s-1] is highly recommended but not necessary for the implementation of the following steps. Part I and Part II here below are based on the use of the tezos-signer daemon and a unix socket connection, therefore the following instructions are easier to understand after digesting the discussion on page [s-2].

It is strongly recommended to try experimenting first on the zeronet network (virtual xtz) before making real changes on the mainnet (real xtz)

---

PART I: set the access to the baker secret key only with root privilege

If the secret_keys file stored in the folder ./.tezos-signer can be accessed only with root/administrator privilege, a possible intruder has to break in the machine but also acquire root access (and since the key is encrypted also decrypt the key) in order to take possess of the fund in the baking account. In addition after setting the secret_keys file with root access, the machine running the node can be left unattended without fearing that a physical intruder can export the secret key of the baker, for example on a usb flash drive. The last security outcome is that any operation with ./.tezos-client that requires the secret key of the baking account (e.g. transfer of xtz) is prohibited unless root privilege of the secret_keys file and the socket file (see below) is revoked and <user> access is restored.

The method uses a unix socket connection (see page [s-1] for details). The first step is to copy the key files in ./.tezos-signer, if the folder does not exist, then as a <user> (e.g. tzuser) from /home/tzuser, type mkdir .tezos-signer. Now the secret_keys file can be removed from the original location, ./tezos-client. Then launch the tezos-signer program:
./tezos-signer -d /home/tzuser/.tezos-signer launch local signer -s /home/tzuser/.tezos-signer/socket
assuming the name of the <user> is "tzuser". And now establish a connection between the ./.tezos-signer folder where the key is stored and the folder ./.tezos-client where the key will be accessed by the tezos program
./tezos-client import secret key tzuser1 unix:/home/tzuser/.tezos-signer/socket?pkh=tz1-----pkh----- -f
assuming that "tzuser1" is the alias of the baking account (the flag -f at the end of the command simply enforces the import command). The secret key is still stored only in the folder ./.tezos-signer (see [s-2] for details).

The status of the file secret_keys now can be changed with the following commands typed as root/administrator:
chown root secret_keys
chgrp root secret_keys
chmod 660 secret_keys
in this way the key can be read only by the root/administrator. By doing so, the programs that need to access the key should also run with root privilege, which is done using the command "sudo". The commands to launch the tezos-signer is now the following:
sudo ./tezos-signer -d /home/tzuser/.tezos-signer launch local signer -s /home/tzuser/.tezos-signer/socket
at this point the password for the <user> tzuser needs to be provided, followed by the password for the encrypted baker account "tzuser1" stored in the secret_keys file (input required only one time). Note that every time the tezos-signer demon is stopped a socket file in ./tezos-signer needs to be deleted (no root privilege is required).

The tezos-baker-xxx and tezos-endorser-xxx commands are the following:
sudo ./tezos-endorser-xxx -d /home/tzuser/.tezos-client -R unix:/home/tzuser/.tezos-signer/socket?pkh=tz1-----pkh----- run tzuser1
and
sudo ./tezos-baker-xxx -d /home/tzuser/.tezos-client -R unix:/home/tzuser/.tezos-signer/socket?pkh=tz1-----pkh----- run with local node /home/tzuser/.tezos-node tzuser1
The programs assumes different names with the zeronet or mainnet network. For the zeronet: tezos-baker-alpha and tezos-endorser-alpha, for the mainnet: tezos-baker-004-Pt24m4xi and tezos-endorser-004-Pt24m4xi.

If the endorsement program fails with Error: wrong predecessor, it helps to add the flag --endorsement-delay 5 at the end of the tezos endorser command, e.g. sudo ./tezos-endorser-xxx -d /home/tzuser/.tezos-client -R unix:/home/tzuser/.tezos-signer/socket?pkh=tz1-----pkh----- run tzuser1 --endorsement-delay 5. The number can be further reduced (I think the default is 10 seconds)

As a general precaution the "sudo" command should be disabled because it allows for anyone with access to a user account to take full control of the machine. However certain "sudo" commands should be enabled for the method described here to work smoothly. As a root/administrator type visudo and at the end of the file that will pop up, add the following lines:\

tzuser ALL=(root) !ALL
tzuser ALL=(root) /home/tzuser/tezos/tezos-signer
tzuser ALL=(root) NOPASSWD:/home/tzuser/tezos/tezos-endorser-xxx
tzuser ALL=(root) NOPASSWD:/home/tzuser/tezos/tezos-baker-xxx
tzuser ALL=(root) NOPASSWD:/usr/bin/kill
tzuser ALL=(root) /usr/bin/umount
tzuser ALL=(root) /usr/bin/mount
tzuser ALL=(root) /bin/yum
tzuser ALL=(root) /bin/rpm

in this way "sudo" can be used only to run tezos-signer, tezos-endorser-xxx, tezos-baker-xxx, and few other commands, nothing else. Please replace "tzuser" with the name of the <user> running the tezos node and tezos-endorser-xxx, tezos-baker-xxx with the correct names for the zeronet or mainnet network. To kill the processes tezos-signer, tezos-endorser-xxx and tezos-baker-xxx the command sudo kill -2 pid show be used (pid is the identification number of the process).

---

PART II: encrypt the folder ./.tezos-signer when the machine power is off or when the node is not running

The main advantage of having the folder ./.tezos-signer encrypted is to secure the secret data from hard drive or SD card theft.
This is done with a program called "ecryptfs". First install the package with this command (as a root/administrator):
dnf install ecryptfs-utils
or similar one, like yum, apt-get, pacman, emerge. Then type: modprobe ecryptfs\

I assume the manager of the node is the only <user> (e.g. tzuser) allowed to have access to the secret_keys file, and the secret_keys file can be only accessed with root privilege as shown in PART I. The first time the program "ecryptfs" is used, the folder ./.tezos-signer should be empty. Therefore to prevent accidental loss of data, all the files should be moved in a temporary location. As a user type:
mkdir /home/tzuser/temp
then as a root administrator, move all the files in the new location:
mv /home/tzuser/.tezos-signer/* /home/tzuser/temp

To start "ecryptfs" as a user just type:
sudo mount -t ecryptfs /home/tzuser/.tezos-signer /home/tzuser/.tezos-signer

The first time this command is typed, the program will ask some questions about security measures, password etc (some info here). It is important to remember these choices because they will be asked again upon remounting the folder.
Now all the files in the temporary location can be put back. As root type:
mv /home/tzuser/temp/* /home/tzuser/.tezos-signer

The files in the folder can be edited, read, etc. like any other file. Make sure the group/ownership is preserved and the secret_keys file has root privilege and limited read/write access. When the node is stopped or before the machine is turned off, the folder should be unmounted with:
sudo umount /home/tzuser/.tezos-signer
It is possible to open the files in the unmounted folder but the content will include "strange things", everything is now encrypted. Even when the machine is turned off abruptly (e.g. power surge or theft) while the node is still running, the folder is forced into the unmounted state (encrypted).

---

PART III: change the solo-baker account and delegate the contracts to a new baker account

For solo-bakers with a 3 accounts-scheme (page [s-1]), it seems wise to delegate to a different baking account once in a while, assuming the delegate account (contract or secondary account) is delegatable, that means it can be delegated to another baking account. To find out if the contract/secondary account is delegatable:

./tezos-client rpc get /chains/main/blocks/head/context/contracts/<pkh_contract>/delegatable

then simply create a new account with:
./tezos-client gen keys <new_baking_account>
transfer some xtz (needed for the deposit) to the new baking account and register the account as a delegate:
./tezos-client register key <new_baking_account> as delegate
then remove the delegate from the old baking account with:
./tezos-client withdraw delegate from <pkh_contract>
and delegate to the new baking account:
./tezos-client set delegate for <pkh_contract> to <alias_new_bake_account>

Some funds should be left in the old baking account to cover the deposit during the cycles in which baking/endorsing have been already assigned to the old baking account). It will take 7 cycles for the new baking account to begin to endorse/bake blocks, however during this the old baking account will continue to endorse/bake even after the contract has been delegated to the new baker account (I tried on the mainnet and it works).

---

FINAL REMARK: because the cost of setting up a RPI3 node is very small, running more than one node should not be a problem. The advantages are: 1) spread the rolls over different accounts, each one located on a separate node 2) if something goes wrong on one node (e.g. hardware failure, blockchain problems, or security breach), the account on the troubled node can be moved to an another node and continue the operations smoothly (careful with double baking!). In addition having an additional node on the zeronet allows for experimenting new features.

---

Next in my to do list:

• SoftHSM + pkcs11-tool + small signer program
• interface Tezos with ZymKey 5 secure module, first release end of August (Zymbit)

---