My father in law loves modifying his model trains and was looking for a way to add interior lighting. I had some spare LED strips, which are also 12 Volt, just like his train tracks.
The issue we ran into however, was of course, that the LED wouldn't turn on if the power is reversed to make the trains go in the opposite direction.
I was thinking of a solution using 4 diodes to create a rectifier and then found the Diotec S250K, a bridge rectifier.
The S250K fits quite nicely on LED strips. Now the trains have their lights on in either direction.
Yubico has a write-up describing how to configure GPG4Win to use a Yubikey for PGP and even SSH authentication on Windows 10. I ran into 2 issues however and am sharing my steps and solution here.
Issue 1 - No such device
C:\>gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
Running the card-status command I only got "No such device" errors. A suggestion I found was to use reader-port Yubico YubiKey in the scdaemon.conf, but that didn't fix the issue.
Enabling logging and debugging
In the scdaemon manual are some helpful options that helped me construct the following scdaemon.conf:
verbose
debug-level 4
log-file C:\scdaemon.log
Restarted the gpg-agent, connected the Yubikey and ran the card-status command again.
Along with other log lines, the log file now contained these lines:
A recent update of theGoogle Authenticatorapp on Android brought an export/import feature. This enables users to copy their 2FA codes to a new device.
The format of the export seems to not be publicly documented (yet?). I believe that this export function is quite interesting and would like to see innovative solutions for back-up or interoperability between devices. It would also be in the general public's interest if there would be a single import/export format for 2FA codes and this one looks promising to me.
This blog post contains my interpretation of the export data. I hope this enables other developers to come up with new cool solutions that use the exported secrets.
Python implementation is available in my Github Repo.
** NOTE THAT THE 2FA CODES ARE SECRETS THAT YOU SHOULD TREAT AS SUCH! **
An interesting blog about the update was published at Ctrl blog.
Back in 2016 I was at a hotel where they had nice looking light from beyond the bed with LED stips. We already had a board behind our bed that would be a nice location the some LED strips like that. Through some investigation I quickly learned that an easy install solution was not available for the requirements that I had;
LED strip with high PWM frequency
On/off and dim controllable in the dark while in bed
Nice looking
In some public places where they use LED bulbs or strips I notice the flickering when the frequency is too low. Especially when it's the only light source in the room and the lights are dimmed. This is quite annoying and feels like I'm experiencing a low frame rate in real life. So the first requirement for this project was the PWM frequency should be high enough to not notice the blinking.
The light should have a very basic interface where it would be possible for me and my girlfriend to turn on/off the light and control the dim level. Doing some research I found some nice looking buttons online that even had a ring of light to make finding the buttons easier at night.
Lots of LED drivers are available on the market, however I couldn't find one that would allow me to connect two buttons to turn the lights on/off and also control the dim level. So I had decided to build my own driver. Having some experience with ATmega and ATtiny the choice was use work around an ATtiny85.
I don't have an education in electronic engineering, using any information from this blog is at your own risk.
Most LED strips that I could find at the time required 12V power supply. I wanted my design to work with any power source that is suitable for the connected LED strip. Therefore power source is connected directly to the output and controlled with a MOSFET. The ATtiny that I choose as controller requires a maximum of 5V. I have some LM7805's laying around which convert any input voltage of 7-35V to 5V, with a maximum of 1A. This is quite suitable to power the ATtiny85.
Schemas
Choosing the right MOSFET turned out more difficult than expected. I asked some colleagues that also like to do electronics and finally choose the IRFZ44N. The board contains a port for small interactions with an expansion. The current code support a KlikAanKlikUit RF receiver (433MHz).
After designing the circuit I ordered the boards online from Aisler. Living in the Netherlands the order from Germany didn't take long to arrive. You probably can image how exited I was to put everything together and test it out.
The PCBs from Aisler
That went better than expected! The software I had written worked as planned and I could control the LED strip with the switches. Short presses turn the light on or off and keeping the button pressed cycles through 6 dim levels.
Mounting he LED strip behind the bed was done with some simple profiles. To make the light come from behind the bed I made some small pieces of wood that are used to make a 90° angle of the strips to the bed.
Experimenting the pot resistors, I wanted to dim the light rings because they were way to bright at night. Started with 1kΩ, then 10kΩ and finally 50kΩ.
(Never really got to finish this post, but wanted to publish it anyway. If you have questions, feel free to leave ask them below.)
What seems to be missing however is an actually vulnerable implementation. Allow me to explain.
Just like the currently available public exploit, my idea was to send SSH2_MSG_USERAUTH_SUCCESS instead of SSH2_MSG_USERAUTH_REQUEST. To get this done I choose to patch OpenSSH and let it handle the rest of the SSH protocol for me.
$ sed -i 's/SSH2_MSG_USERAUTH_REQUEST/SSH2_MSG_USERAUTH_SUCCESS/g' sshconnect2.c $ autoreconf $ ./configure $ make
Next I started the libssh 0.7.5 example ssh_server_fork, fired up my patched OpenSSH and... Nothing.
Looking at the server log:
[2018/10/22 01:15:55.264597, 3] ssh_packet_socket_callback: packet: read type 52 [len=124,padding=73,comp=50,payload=50] [2018/10/22 01:15:55.264732, 3] ssh_packet_process: Dispatching handler for packet type 52 [2018/10/22 01:15:55.264799, 3] ssh_packet_userauth_success: Authentication successful [2018/10/22 01:15:55.264853, 3] ssh_packet_socket_callback: Processing 80 bytes left in socket buffer ... [2018/10/22 01:15:55.267131, 3] ssh_message_channel_request_reply_default: Sending a default channel_request denied to channel 0 [2018/10/22 01:15:55.267222, 3] packet_send2: packet: wrote [len=12,padding=6,comp=5,payload=5] [2018/10/22 01:15:55.267363, 3] ssh_socket_unbuffered_write: Enabling POLLOUT for socket [2018/10/22 01:15:55.269561, 1] ssh_socket_exception_callback: Socket exception callback: 1 (0) [2018/10/22 01:15:55.269667, 1] ssh_socket_exception_callback: Socket error: disconnected
So, I was successfully authenticated, but then disconnected. As described in RFC4252 §6, message 52 is SSH_MSG_USERAUTH_SUCCESS.
Source code diving time! I'll not go into all the details that I went through to get to understand libssh and cut right to it. Looking at examples/ssh_server_fork.c, this is essentially what's going on:
setup the libssh server and, when a client connects
call handle_session
setup libssh callbacks, including the auth_password_function
while (sdata.authenticated == 0 || sdata.channel == NULL)
ssh_event_dopoll(event, 100)
So what is this sdata? If we look at the auth_password function that was assigned as callback function for auth_password_function, we see:
This part of the example implementation of ssh_server_fork is authenticating the user by the provided username and password and only if these match, sdata->authenticated is set to 1. The while-loop will therefore never exit when the exploit is used to authenticate.
The other examples provided in the libssh source package, all use a local state variable to check if the user properly authenticated. I have yet to find any service that implements libssh in a different way.
Not all libSSH servers will necessarily be vulnerable to the
authentication bypass; since the authentication bypass sets the internal
libSSH state machine to authenticated without ever giving any
registered authentication callbacks an opportunity to execute, servers
developed using libSSH which maintain additional custom session state
may fail to function correctly if a user is authenticated without this
state being created.
If you have found a service implementation that is actually vulnerable, I'd be very interested to hear about it in the comments.
Let's say you have two systems that can connect to the same server. Client1 contains a private key and its SSH agent is forwarded to the server. Now you want to use a private key in that agent on Client2. There are ofcourse some security concerns when using SSH Agent Forwarding, so please do a proper security assessment before using any of this information.
With my new laptop I wanted to ensure my private keys would be safe. This is a brief summary of the steps I've taken to use a private key in my laptop's TPM to authenticate with OpenVPN and SSH.
UPDATE 2022-04-13:
I've switched to putty-pkix [6] because I had issues with newer OpenSSH only allowing SHA256 signatures and pagaent not providing valid responses.
agent key RSA SHA256:L1iUIhjfKejEONe0TFU3TaWkNwE2O0xWF/09K7P8WnA returned incorrect signature type
Create a virtual smart card
Ensure the TPM is activated.
Run: tpm.msc
Start a Command Prompt as admin.
Create a Virtual Smart Card [1].
Run: tpmvscmgr.exe create /name "[hostname] VSC" /pin prompt /adminkey random /generate Enter PIN: ******** Confirm PIN: ******** Creating TPM Smart Card... Initializing the Virtual Smart Card component... Creating the Virtual Smart Card component... Initializing the Virtual Smart Card Simulator... Creating the Virtual Smart Card Simulator... Initializing the Virtual Smart Card Reader... Creating the Virtual Smart Card Reader... Waiting for TPM Smart Card Device... Authenticating to the TPM Smart Card... Generating filesystem on the TPM Smart Card... TPM Smart Card created. Smart Card Reader Device Instance ID = ROOT\SMARTCARDREADER\0000
Generate a signing request and have the request signed to obtain a certificate.
Create a request template in Notepad and save this as TPM-cert-template.inf [2]. [NewRequest] Subject = "CN=[hostname],O=[Organisation],L=[Location],ST=[State],C=[Country]" Keylength = 2048 Exportable = FALSE UserProtected = TRUE MachineKeySet = FALSE ProviderName = "Microsoft Base Smart Card Crypto Provider" ProviderType = 1 RequestType = PKCS10 KeyUsage = 0x80
Then generate a Certificate Request (CSR): certreq -new -f TPM-cert-template.inf TPM-cert.csr
Send the CSR to your CA and have it signed. You should get a certificate in return.
Install the certificate
Double click the received certificate file (most likely .crt or .cer).
Click on the "Install certificate" button and follow the wizard.
When it's done, obtain the fingerprint of the certificate from the Details tab.
Configure OpenVPN to use the cryptoapi and certificate
Edit the OpenVPN profile.
Instead of a "cert" and "key" configure "cryptoapicert" with your fingerprint: cryptoapicert "THUMB:92 50 9d ea 52 f4 95 ee be a1 c0 4f ab f8 a2 2b 4d 91 0c 0a"
Save the profile and connect.
Enable SSH authentication with the Virtual SmartCard
Download and install puttywincrypt [3].
Configure putty to use the certificate under Connection -> SSH -> Auth by entering [4]: cert://*
Update: WinSCP
WinSCP turned out to work with the certificate through pageant when using "SCP" as protocol and checking the checkbox in SSH, Authentication "Attempt authentication using Pageant".
Update: Listing wmic path win32_PnPEntity where "DeviceID like '%smartcardreader%'" get Caption,DeviceID
Update: Dell XPS 13
After updating my XPS 13's TPM firware to 2.0 I was no longer able to use the TPM certificate for authentication. Trying to revert back to firmware 1.2, that showed to be working before, failed with an error "Invalid source version". Contacting Dell did not help. They answerd my mails for support with links to online content that I had already found or was irrelevant and finally let me know "TPM is not supported by [Dell]. If the problem is not solved I advise you to contact Intel." Thanks to a post I've found on Reddit [5] I was finally able to revert back to version 1.2 and issue a new certificate.
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
.JPG)
