https://www.ledger.com/blog/software-wallets

We can distinguish two prevalent types of wallets: software and hardware wallets. They fulfill the same function, but in a different way. Software wallets are considered simpler to use: a single program is enough to create, validate and sign transactions. With a software wallet, it is not necessary to create the transaction on the software and confirm it on a hardware device.

Two weeks ago, Forbidden Stories unveiled a targeted attack against thousands of people around the world. This attack exploited vulnerabilities on Android and iOS, to install spyware developed by the NSO Group: Pegasus. This malware is able to monitor the whole activity of the device, and to exfiltrate personal information: SMS, WhatsApp and Signal conversations, phone calls, etc. This article explains how, under these conditions, such a malware would be able to extract all the secrets of a software wallets, and the differences from a security point of view between software wallets on mobile phones and desktop computers.

This article is intended to be not very technical. To keep it relatively simple, only basic features will be discussed.

Protecting secrets

What is stored in a crypto wallet?

Wallets do not actually store the users’ cryptocurrencies: they only store the secrets, notably the private keys, that allow to access the cryptocurrencies and the ability to spend them. These private keys are mostly ECC (elliptic curve cryptography) private keys on different curves depending on the blockchain. The most common curves are secp256k1 (Bitcoin, Ethereum…), Ed25519 (Monero), or BLS12-381 (Ethereum 2).

These keys are used to sign transactions, and more generally to interact with blockchain assets.

The storage of these keys depends on the type of wallet: deterministic or not. A Hierarchical Deterministic (HD) wallet allows the creation of a tree of keys from a single master secret called the seed (cf BIP44). This seed is often derived from a mnemonic sequence of 12, 18 or 24 words randomly generated or chosen by the user (cf.BIP39). These mnemonics allow to limit the number of keys to be stored: they can be recomputed anytime from the seed. HD wallets only store this mnemonic or the seed.

Non deterministic wallets generate a new key for each use and must store all of them. Non-deterministic wallets can’t be easily migrated to another wallet since backups are not compatible.

The main security features of a wallet consist in generating, storing and using these secrets properly. There are different levels of security against different types of threats:

• Protection against “evil maid” attacks : An attacker with temporary access to the wallet mustn’t be able to add a backdoor inside the wallet allowing to steal the PIN or the password protecting secrets.
• Secure cryptographic material : Keys and nonce generated by the wallet must never be predictable. Furthermore the knowledge of secrets (except the seed) generated at some point in time shall not allow to predict the secret to be generated in the future.
• Protection at rest : If an attacker obtains persistent data of a software wallet, they must not be able to extract the keys.
• Protection during secret use: When the wallet is unlocked, the keys must not be accessible by an attacker or a malware.

Hardware wallets

The security model of a hardware wallet aims at obviating these security threats. Hardware wallets protect against malware by design. They are independent devices which sign transactions on their own. The cryptographic materials always stay inside the device and are never sent to the software application to which they communicate. The communication interface is always simple which drastically reduces the attack surface. It can be USB, Micro SD or camera + screen (through QR code), or Bluetooth Low Energy.

Furthermore, hardware wallets embed a screen directly into the device allowing the user to verify the actions he’s about to do when he interacts with his secret keys. These manual checks on devices are a very efficient countermeasure against malware on the computer/mobile. Where malware on a computer/mobile device could access the secrets (seed or private keys) or even swap/modify addresses or amounts when the user is performing a transaction, this is not possible with a hardware wallet.

Hardware wallets are also designed to protect against “evil maid” attacks and against an attacker with physical access. Depending on the hardware wallet, they have different levels of security, but in all cases they are designed to secure against these threats. A detailed description of Ledger Nano threat models can be found here.

Software Wallets

Regular software wallets protect secrets with regular means: security mechanisms of the operating system on which they run and sometimes an access control based on a PIN or a password.

In the following, desktop (Windows, macOS, Linux) wallets and mobile wallets are considered. The main differences between them mostly rely on the security mechanisms offered by the operating system.

Software wallets on a computer

Several popular wallets, such as Electrum, Exodus, Atomic or Bitcoin core, run on computers.

On a computer, security mechanisms offered by the operating system to isolate a wallet process from other processes are limited. Most apps are run by the same user, and apps are allowed to read other application’s data.

The security of these software wallets mainly relies on the security of the password that protects them, and also on the fact that no malware runs on the OS (which is quite difficult to guarantee, see recent news regarding Pegasus).

Most of the time, the seed is stored in an encrypted container protected by a password.A straightforward attack consists, for a malware or a remote administration tool, to retrieve this encrypted container and send it to the attacker. Then the password can either be brute-forced or obtained through using a keylogger.

In a scenario where an attacker only manages to access the encrypted container (the attacker finds a USB key containing a wallet, or installs malware on a computer, but the victim never opens his wallet application), the attacker has to brute force the password.

Most passwords are bad. There are billions of passwords that leaked on the web, and many people tend to reuse their passwords for several services. Ready-made tools allow you to retrieve passwords for cryptocurrencies wallets, such as btcrecover or hashcat. Passwords can be complex, but behind each wallet there is real money, hence attackers won’t hesitate to invest resources to break such passwords.

Two basic security principles to keep your passwords secure are to use a password manager, and to never reuse your password for different purposes.

The most concerning threat for software wallets are dedicated malware and stealers, developed specifically to drain your funds. Such malware, such as KPOT or ElectroRAT, do not even have to bruteforce your password: they can directly capture it when you enter it, decrypt the wallet configuration data, and exfiltrate the seed.

Here is a toy application, developed for this article, that targets the Electrum wallet (though it could have been another software wallet). It simulates a malware that steals the user password when it is entered by the victim. Password is then used to decrypt the wallet data, and to display the seed:

As you see, even if the password is complex, the app is able to retrieve it as it directly sniffes it in memory.

This example is very similar to the recent .SCR malware campaigns used to steal cryptocurrencies. Criminals used social engineering techniques to trick users into downloading a malicious screensaver. This screensaver was actually stealing information from the computer’s victim, including wallet and cryptocurrency exchange information.

To conclude on software wallets running on computers:

• In most cases software wallets running on computers protect the user’s seed using a password.
• The access control for these wallet files mainly rely on the security of the computer. In practice, it is hard to protect computers from malware, and as cryptocurrencies become mainstream, attacks against wallets will become more and more sophisticated.
• Using such software wallets to secure digital assets is not a good idea. Any specialized malware will be able to get the wallet files and find the passwords offline, or get the password through a keylogger.

Software wallets on a smartphone

Android and iOS smartphones offer by default security features that are not widely used on desktop operating systems.

Mobile operating systems offer app and user data protection. In particular, app sandboxes are mandatory for all apps. This is not the case on, for instance, Windows: by default, any application can access user data.

Hence, a malicious app cannot read data from another app, except if:

• It finds a vulnerability on that app.
• Or it manages to escalate privileges, for example by exploiting a kernel vulnerability allowing it to gain root access to the system.

Unfortunately, such attacks exist. They are much easier on outdated versions of Android and iOS, and on older or cheap devices where third-party code is often less secure.

On an up-to-date OS, these attacks are harder but not remotely unfeasible. For example, Ian Beer showed an extremely impressive zero-click attack on iOS 13.5 in December 2020. Guang Gong presented an exploit chain to remotely root a wide range of Qualcomm-based Android devices in June 2020. And, two weeks ago, Forbidden Stories unveiled that NSO Group used an exploit chain to target recent iOS and Android devices using 0-day vulnerabilities.

Less sophisticated attackers can use local vulnerabilities allowing them to extract wallet data from a malicious application. Vulnerability brokers such as Zerodium pay up to $200,000 for a privilege escalation to root on Android and iOS, but up to $1,500,000 for remote attacks.

We studied a couple of Android/iOS wallets. Their security depends on the app itself, but also on the security features of the underlying OS. Of course, when the security of the operating system is defeated, the application is not secure anymore

Two methods to protect the seed are commonly used:

• Password protection – wallet data is protected by a password entered by the user. The design is the same as for desktop wallets. In practice, data is harder to extract than from a computer, as retrieving app data from a malicious app is technically more difficult, for the reasons explained above. However, retrieving the password once the data has been stolen is in practice easier: entering complex passwords on mobile phones is tedious, hence users tend to choose simpler ones. Moreover, key derivation mechanisms (used to create a key from a password) on mobile devices are usually simpler to break, as they are often more lightweight for performance reasons.

• Coinomi and Metamask are examples of such wallets.

In the following video, we show another toy app developed for this article. It is a malware disguised as a fake Bitcoin ticker widget. Malware exploits a known vulnerability on an unpatched device to get a root acess on the device, and to exfiltrate the encrypted seed to a remote server. The server then bruteforces the password to decrypt the seed.

This method is not specific to a wallet. It can be (more or less) easily adapted to any password protected wallet. Here is he same example with Coinbase Wallet:

• Security based on the Android Keystore (or iOS Keychain) – In this case, wallet data is encrypted with an encryption key stored in the Android Keystore (iOS Keychain). These services were initially designed to securely store encryption keys, and many apps use them to generate a key that will encrypt all the sensitive user data.Applications using the Keystore implement the following mechanism:
  • The app asks the Keystore to generate an encryption key for a given identifier. Keystore generates the key and stores it securely.
  • When the app wants to encrypt or decrypt a blob, it sends the blob along with the key identifier to the Keystore.
  • Finally, the keystore checks if the app has actually the rights to use this key and sends back then output data to the app.

With this model, the app can’t know the value of the key but can use it. It is also possible to associate additional access controls to the key: for example, key access can be conditioned to a user authentication (request for a PIN or unlock pattern).

This mechanism can provide additional security, compared to password based protection. Indeed, on recent phones, the Keystore is backed by a Trusted Execution Environment (TEE), or sometimes a Secure Element.

That means an attacker with root privileges won’t be able to extract encryption keys from the keystore. Nevertheless, they will be able to use the Keystore as a decryption oracle, and to encrypt or decrypt any data they want.

Keystore offers encryption, but also signing services. So, could a wallet protect its encryption keys, making them difficult to extract? The answer is unfortunately no: software wallets do not use Keystore to sign transactions, and private keys are always manipulated in plaintext by the app.

This is for a simple reason: KeyStore and KeyChain offer generic signature and encryption services, but don’t support the cryptography used in cryptocurrencies. For instance, the KeyStore implements ECDSA Signature but only on NIST curves defined in FIPS 186-4 (P-224, P-256, P-384 and P-521). Bitcoin uses another curve, secp256k1, which is not supported yet.

To summarize, Keystore and Keychain are good services to protect secret and private keys. They can offer some security by encrypting sensitive data: some classes of vulnerabilities (arbitrary file read, for example) will be tacked by Keystore encryption. However, if a root privilege escalation is not enough to extract the key values from a hardware-backed Keystore, it is sufficient to decrypt sensitive data. An attacker able to instrument the app is able to retrieve its secrets.

To conclude on mobile wallets:

• The isolation mechanism between apps provided by iOS/Android raises the bar for security compared to a software wallet running on a computer. The attacker needs first a privilege escalation to access app data. This is feasible on outdated devices. Skilled attackers (Ian Beer did it in 6 months alone but… It is Ian Beer) can also do it on recent, patched devices.
• Key protection services (KeyStore, KeyChain) could add an additional layer of security for protecting secrets at rest. Nevertheless, as they don’t support cryptographic algorithms for cryptocurrency applications, key can still be extracted.
• In all cases, an attacker with a root access can either retrieve the seed at rest, when used, or leverage the user’s rights to empty the wallet using the software wallet as an oracle.

Here is a last example of a toy spyware targetting the Blockchain.com wallet (though this could be performed on many other wallets just as easily). It is installed remotely, and monitors the wallet. Once user has authenticated using his fingerprint, encryption key is unlocked and wallet data is decrypted. The spyware instruments the app to retrieve this encryption key. It then exfiltrate the key and the wallet data to a remote server:

Conclusion

As a conclusion, software wallets have different levels of security. However, their threat model does not cover the case of a malware running on the OS with a privilege escalation. This is by design: the wallet app cannot be more secure than the operating system it runs on.

• The isolation mechanism between apps provided by iOS/Android raises the bar for security compared to a software wallet running on a computer. The attacker needs first a privilege escalation to access app data.
• Key protection services (KeyStore, KeyChain) could add an additional layer of security for protecting secrets at rest. Nevertheless, as they don’t support cryptographic algorithms for cryptocurrency applications, keys have to be manipulated directly from the app, so they offer a limited protection.
• In all cases, an attacker with a root access, can either retrieve the seed at rest, when used, or leverage the user’s rights to empty the wallet using the software wallet as an oracle.

https://www.ledger.com/blog/ssh-with-tpm

In this protocol, users are required to be authenticated. They can do this with passwords, files containing private RSA keys, hardware devices such as Ledger Nano S and Ledger Nano X, etc.

Some authentication means are more secure than others: using a hardware device designed to store a private key without making it possible to ever extract it is more secure than storing the private key in a file. Unfortunately the most secure ones are also more painful to use. Users who have their keys on a device need to carry the device with them, need to type their PIN code every time they initiate a SSH session, etc. This makes it quite difficult to advocate ways more secure than passwords and files for use cases where the security of the access is not the priority.

So the question is: is it possible to store the authentication material more securely than in a file (which can be stolen by some malware), without changing the user experience?

And the answer is: yes, using a TPM!

Some history

For quite some time, computers have been able to directly embed a security chip. This chip, named Trusted Platform Module (TPM), provides many features including the ability to protect private keys used in public-key cryptography.

As it is embedded in computers, there is no need to plug a device in the computer in order to use it. This is therefore considered as less secure than a hardware device which can be stored in a different place from the computer (this enables enforcing the principle that while the device is not connected to the computer, no malware can use the secrets stored in it).

So TPM is not the “best security”, but it is still much more secure than using files such as $HOME/.ssh/id_rsa to store private keys.

How can TPM be used with OpenSSH on Linux? With a project named tpm2-pkcs11, following instructions available on many websites for many years, including on the official documentation from its code repository.

Now, what’s the news? This software is now finally packaged in Ubuntu and Debian, which makes it finally available to most Linux users!

More precisely here is a timeline:

• In 2014, the main specifications for TPM 2.0 were published. To interact with a TPM from the software, there was a standardization effort, and two incompatible software stacks were created: the one from the Trusted Computing Group (TCG), called TPM Software Stack (TSS), and the one from IBM, also called TPM Software stack.
• In 2018, the project tpm2-pkcs11 was created to provide a PKCS#11 interface to a TPM 2.0, using TCG’s TSS. PKCS#11 is a standard which defines an Application Programming Interface (API) named Cryptoki to use tokens storing cryptographic keys. As OpenSSH supported using a PKCS#11 interface to perform user authentication, this enabled using TPM to store the keys used for SSH authentication.
• In February 2019, tpm2-pkcs11 was added to Fedora 29.
• In September 2019, CentOS 8 was released with this package.
• In April 2020, tpm2-pkcs11 was added to Debian sid. Unfortunately it did not contain the program tpm2_ptool which is necessary to easily create keys. This issue was reported in Debian bug #968310.
• In January 2021, Debian’s package was fixed (and the maintainer acknowledged my help!).
• In April 2021, Ubuntu 21.04 Hirsute Hippo was released with the fixed package.
• In August 2021, Debian 11 Bullseye was released with the fixed package

Now tpm2-pkcs11 is available on Debian, Ubuntu and several other Linux distributions listed on Repology.

Using tpm2-pkcs11

On Debian 11, here are the steps to generate and use a new SSH key stored securely by the TPM:

1. Install command tpm2_ptool and library libtpm2_pkcs11.so.1, which are provided by two packages:

2. Check that the system can use a TPM 2.0. If one of the following checks fails, it could mean that the system does not have a TPM, or has a TPM 1.2, or has a TPM 2.0 which is disabled in the BIOS settings:

3. Add the current user to the group which can access the TPM device /dev/tpmrm0. On Debian and Ubuntu, users need to belong to a group named tss (thanks to configuration provided by tpm-udev package). The following command adds the current user to this group:

Initialize a user store, protected by a password and a SOPIN and create a key, for example an Elliptic Curve key on the curve named “NIST P-256” (also known as “secp256r1”):

4. The acronym SOPIN means Security Officer Personal Identification Number and is a concept from PKCS#11’s specification. In simple use cases, it may be seen as a “recovery password” which enables modifying the password when for example it has been lost.

5. Display the public key of this new key:

6. Configure the new public key in a server, for example by writing it in $HOME/.ssh/authorized_keys or in GitHub’s account settings or in any other location where SSH public keys are used.

7. Configure the SSH client to use tpm2-pkcs11 to connect to the server, for example by writing this in $HOME/.ssh/config (client side):

Connect to the server (N.B. the previous step can be skipped:

Future work

The previous section presented how to create a new key in the TPM. While this enables using a TPM to protect SSH authentication, there are two features which are needed to make this a real alternative to using files to store private keys:

• Feature #1: importing existing SSH keys into a TPM instead of creating new ones (which enables smooth transition to TPM storage, backing up the keys, in case the computer is broken or lost, etc.).
• Feature #2: using SSH keys without password, like unprotected private key files (this feature is more secure than key files as the protected key cannot be extracted from the TPM).

I implemented both features in tpm2-pkcs11 and submitted them in Pull Requests #681 and #695. Feature #1 was also presented in May during the weekly online call of tpm.dev community and the recording is available on https://developers.tpm.dev/posts/14389750.

So both features are likely to become available in a future release of tpm2-pkcs11.

By the way, for curious readers who want to understand the internals of tpm2-pkcs11, I published an article about them at SSTIC 2021 conference, named Protecting SSH authentication with TPM 2.0 (article in English, presentation in French). Moreover readers who want to try things without touching a real TPM could be interested in the section “Emulating a TPM 2.0” of this article.

_{(Illustration: Rainer Knäpper, Free Art License)}

https://www.ledger.com/blog/booba_nft

The 3rd of November 2021, Booba (the french rapper who created the label La Piraterie Music) put a set of 5 NFTs up for sale, for a total of 5000 of each of these animated cards. The totality of these NFTs were sold in a few days for 150 ETH (0.006 ETH each), that is more than $700.000 at this date. As a bonus, lucky owners of one of these NFTs were allowed to see the exclusive music video TN since the 8 November 2021.

Les rappeurs m’envient, sont tous en galère.
– Boulbi, Ouest Side

We were a bit curious and wondered how the music video was protected and if we could enjoy it even if we didn’t buy any NFTs.

How does the music video protection work?

In order to see the video, owners of the NFTs have to visit the page /mon-nft and use their crypto wallet (such as Metamask or WalletConnect) to sign the Ethereum message "Pour accéder à TN, merci de bien vouloir signer ce message" with the same wallet than the one used to buy the NFTs. Once signed, a POST request with a JSON body following this format is sent by the web browser to a web service hosted on AWS:

A few tests show that messages different from the default one aren’t rejected as long as they are JSON-encoded. For instance: [1337] and "blah" are considered as valid, however messages that aren’t in JSON trigger an internal error instantly.

If the signature associated to the Ethereum address (wallet) and message are valid, the server verifies that the wallet indeed bought one of the NFTs, otherwise the error Tu ne possèdes aucun des NFTs is returned. This last step takes a little more time, which let us formulate the following hypothesis. If we find on the Internet a public key that meet these 2 conditions:

• The public key signed a JSON message and the associated signature is public;
• The wallet bought at least one of the NFTs.

it might be possible to replay the message and the signature on the AWS server to retrieve the music video.

The BOOBA TN NFT is also an ERC-20 token (B2O_TN) minted by the smart contract 0x3b73…94dd. We first started by listing all the NFT owners thanks to etherscan.io. At the time of writing, there were 3484 owners of at least 1 of these NFTs. 1516 wallets own more than one of the same NFT, probably to resell one of these later.

Un jour de mon salaire c’est leur assurance vie.
– Boulbi, Ouest Side

1st attempt – etherscan.io

Ethereum messages are encoded using the personal_sign format ("x19Ethereum Signed Message:n" + length(message) + message) before being signed using ECDSA. Since Ethereum transactions are encoded into a different format (RLP), transaction signatures can’t be recognized as valid message signatures. Put it differently, message signatures can’t be found on the Ethereum blockchain.

The first place where we found off-chain Ethereum messages is etherscan.io, which provides a web interface to verify an Ethereum message signature and eventually save it to make accessible via a public URL. We first retrieved all Ethereum messages saved through this service: etherscan.io/verifiedSignatures.

For instance verifySig/2642 shows that the NFT owner of Boring Ape #6743 proved that he also is the owner of the Twitter account ape6743:

He’s also an owner of the NFTs Booba TN as shown in this transaction. However, even if the signature is valid, the message isn’t JSON formatted and can’t be recognized by the AWS server.

Tu n’peux que gagner quand t’as rien à perdre.
– Magnifique, Trône

2nd attempt – snapshot.org

The website snapshot.org allows individuals to vote for proposals by using their Ethereum wallet: Snapshot is an off-chain gasless multi-governance client with easy to verify and hard to contest results. Votes are coincidentally in JSON format.

A GraphQL interface can be used to query the votes database. For instance, the following minimal GraphQL request returns vote IDs where the voter address is 0x668248dF4595e09Aa253B31478312748078F7a20:

The query result shows that this address has been used for 2 votes:

The votes signed by each wallet owning Booba TN NFTs can be retrieved in its entirety with a single GraphQL request. There are 689 results for 140 unique voters.

The address 0x668248dF4595e09Aa253B31478312748078F7a20 bought 5 Booba TN NFTs. As shown previously, this address also voted for the following proposals:

• ens.eth: Ratification of the ENS DAO Constitution
• friendswithbenefits.eth: Proposal: FWB Local

The associated votes are stored on the InterPlanetary File System (IPFS): QmZL5toFBQrPgNDPTpQCukWtcjWeT5x6nou75wMMTm52zM and QmQLSv36j3GLdRjubqpXjpAgwYG77Mop5T9uLCi73r1SUT. The content of the first vote is:

Please note that the URL expires after a period of time and isn’t valid anymore.

Conclusion

This blogpost shows that even if the cryptography powering this NFT event is sound, a basic replay attack was sufficient to break the music video protection. The fix is simple: the message sent to the AWS server should be rejected if it doesn’t match the message sent to the crypto wallet.

La piraterie n’est jamais finie !
– Walabok, Nero Nemesis

Once contacted (finding the right contact was actually the most difficult part), the developers from RenaissanceNFT were super cooperative and responsive. The issue was fixed within less than an hour and the protection access can’t be bypassed anymore.

https://www.ledger.com/blog/laser-improvements

This short post describes some laser station enhancements we made to be able to run our experiments remotely.

Setup problems

Our laser fault injection platform is made of a microscope used to focus a laser source down to a device under test. It is equipped with an infrared camera to observe the internal architecture of the targeted chip, and adjust the laser beam shape. Fortunately, it is equipped with a motorized stage which allows moving the laser beam across the chip from our custom software application. All the tools we developed run on the Linux operating system, and it is therefore possible to use them through an SSH connection, provided you have good internet connection. We faced some latency issues dealing with the microscope camera live image, which we quickly solved by turning on the SSH compression option (-C) which is not enabled by default and greatly reduces the required streaming bandwidth. Nonetheless, at the time some elements still required in situ intervention:

• Controlling the camera light source: a dedicated equipment provides infrared light to illuminate the chip for camera visualization.
• Opening or closing the mechanical camera shutter: this shutter is part of the microscope and must be closed when using the laser.
• Changing the microscope objective: 4 different optical objectives are mounted on a mechanical rotating turret and allow different microscope magnifications.

Below is detailed how we customized our test bench to control remotely the shutter and the light source. In particular, we wanted to limit the cost of those adaptations, and make it available as soon as possible.

Controlling the light source

The silicon substrate of semiconductors is semi-transparent to infrared light, and with an infrared camera, it is therefore possible to observe the internal structure of circuits. For making the observation possible, the circuit must be illuminated with an infrared light source. Our laser microscope was shipped with a dedicated light source equipment, a Hayashi LA-150CE, which has a power switch and a knob to adjust the light intensity, as depicted below. When a laser testing campaign is started, we usually turn-off the light source as it may interfere with the components, especially when samples are thinned.

Looking at the rear of the equipment, we found a “remote” switch and an external connector were available. We understood this light source offers remote control capability through some past millennium connector. Little documentation can be found on the web, but we identified in a Hayashi catalog there exists a LAN Control Unit compatible with this light source. However this product is discontinued. Also, LAN connectivity is not very convenient. In the same catalog, we found the specification for the connector of the light source. Though it is not very detailed, it was enough to try this out.

Remote control pinout from Hayashi products catalog:

This interface provides two main interesting features:

• Digital pins 1 and 8 can be used to switch on and off the lamp by shorting them or not. Pin 8 is actually the ground, so only pin 1 is really relevant.
• The analog pin 2 controls the light intensity with a signal ranging from 0 V (minimum intensity) to 5 V (maximum intensity). When remote mode is enabled, the front panel potentiometer is bypassed and light intensity is directly controlled by this pin.

We decided to build from scratch our own Hayashi Light Remote Controller using the following parts :

• A STM32 microcontroller to host the embedded application code,
• A FT232 USB-to-serial converter to allow controlling the dongle from the USB,
• A AD5621B Digital-to-Analog Converter for the 0 to 5V analog signal generation to control the light intensity.

We designed the PCB using KiCad. To be honest, this design may be a bit oversized: the microcontroller is too big for the current need, and the FT232 may be removed since STM32 devices have already USB capabilities, at the cost of software development time. Our goal was to make it quick and dirty and reuse some of our already designed schematics.

For the fun, and because we believe this is a very promising language, we developed the microcontroller firmware in Rust.

We finally designed a simple plastic enclosure using FreeCAD, and printed it with Sculpteo.

Unexpectedly, the most difficult part of this project was identifying the connector (reference 5710140 from Amphenol for the male side), and also purchase it as it is obsolete and not sold anymore by many suppliers. The part supplier search engine Octopart can help.

All the schematics and design files are available on our GitHub repository.

Controlling the camera shutter

In the microscope, the laser beam and the camera share the same optical path. When the laser is shooting, a fraction of the light is reflected by the silicon and will hit the camera. To prevent sensor damage which can result on the long term in dead pixels, an optical mechanical shutter in front of the camera can be closed. The shutter is manual and requires little to no force to be actuated.

To make remote control possible, we bought a small stepper motor and a TIC T834 Stepper Motor Controller from Polulu. We developed and printed 3D gears and a body to be mounted on the microscope, in order to move the shutter with the motor.

TIC T834 requires a power source to provide the energy to the motor, but as our motor does not draw a lot of current, we shorted the USB power supply of the T834 to power the motor as well. TIC controllers are very easy to setup and use, it is well documented and it took us very little time to control the motor from our software tools. We developed a tiny controller class in Python now integrated in our pystages library.

Stepper motor controllers need to find out the current motor position when it is powered on. This is done with an initialization procedure where the motor will spin until a contact switch tells the controller that the motor is at the zero position. We used a simple switch directly connected to the T834 which has this feature built-in.

The 3D body part we printed was not very accurate and the two gears were not operating correctly at the first time. Using heat we could slightly bend the plastic part to correct the gap between the gears. After a few adjustments, we were able to remotely open and close the camera shutter perfectly!

Mechanical design is available on our GitHub repository.

Final thoughts

Integrating the control of the light source and the camera shutter allowed us to run many laser testing campaigns remotely. It is also more convenient than before, as closing the shutter and switching off the light can now be done automatically when the laser is turned on, whereas it required human physical intervention before and could be easily forgotten.

Regarding the control of the objectives turret, there already exist motorized turrets, but unfortunately they are quite expensive, and it may be tricky to replace. For the moment, we did not find any simple and low-cost solution. Rotating the turret with an external motor is hard, especially because there’s a spring that locks the turret in place when the objective is aligned to the microscope. Also, the weight we can add to the motorized stage is limited. This is still an open issue at the moment, but it does not prevent working remotely, we are just limited to a selected magnification.

Finally, replacing the sample when it is broken still requires access to the lab. Fortunately, it does not happen too often. We may eventually multiplex many circuits on a single daughterboard, so we can burn a few devices before needing physical replacement, yet we did not develop such a solution.