Terminal Server

I have a working Terminal Server that can be used to configure devices connected locally or remotely. It has a “command line interface” with a modular design to create simple command line interfaces that can have actions, parameters and options. I currently have a working TinyCLR application that is using the telnet protocol for remote access.

Additionally, this interface can be access locally using a USB cable. The idea behind this you could attach to the device using a USB cable (CDC or WebUSB) and connect as a “console” or connect remotely into the device using any standard telnet client. However, in this day and age telnet is very much discouraged and my real goal is to create an SSH server. I feel like I’m very close to making this happen :slight_smile:

As a minimum security standard, I would like to support aes-256 encryption and an RSA key exchange. In addition to the TinyCLR telnet server I have created a full dotnet SSH authentication test application that is using only the TinyCLR api set, so it should work once I have the final encryption worked out.

I was successful in porting over AES from the mono project into TinyCLR managed code (it is big and ugly but works). However, I’m missing two api from the existing RSA native driver for the key exchange process. From what I can tell the STM32 native security engine looks to support functions for PKCS1 (version 1.5) that should work for key exchange. Here are the equivalent dotnet signature functions that I need to make this work.

RSACryptoServiceProvider.SignData(data, HashAlgorithmName.SHA1, RSASignaturePadding.Pkcs1)
RSACryptoServiceProvider.VerifyHash(hash, signature, HashAlgorithmName.SHA1, RSASignaturePadding.Pkcs1)

I’m curious as to what the community might think of this project and if the GHI team might consider a discussion about supporting these RSA hashing functions. In case you want to dig a little deeper. Here is the project repo:

4 Likes

Is it a C# implementation?

I know we have everything needed internally. It is a matter of exposing the needed functionality. Do you want to add it here? Issues · ghi-electronics/TinyCLR-Libraries · GitHub

Yes, this is a c# implementation. It’s pretty large and complex so if you are open to providing access to the native AES engine too, I think that would be the best option. :grinning: Here is the repo for the ported AES encryption. It could be cleaned up for sure.

I would be more then happy to open up an issue for it.

1 Like