Hounds

Set your OTP server to in WSJT-X to: https://fotw.xyz/

FoTW will also check 9dx.cc (the default WSJT-X server) as well, so you won't need to change this URL for other dxpeditions.

Foxes

To provision a FoTW OTP key to use in WSJT-X you need to sign a verification log file generated by us then upload it for verification by our servers. A correctly signed verification log will provide a FoTW OTP key instantly which can then be used in WSJT-X. No manual approval is required.

Requirements:

• A valid LoTW certificate for the callsign you wish to use

Step 1 - Download verification log

Click this button to download verification log

Step 2 - Sign the verification log with TQSL

1. Open TQSL. In the menu click "Sign and save ADIF" (do not select upload; you should not upload this log to the ARRL. Only upload this file to fotw.xyz).

   

2. Open the ADIF file you just downloaded, select a place to save the resulting tq8 file.

3. Select the certificate you'd like to use for WSJT-X verification.

4. Verify the details. Leave date range blank.

   

5. Upload TQ8 File to FoTW

   Upload
   Do not share this tq8 file with any other site or person.

Step 3 - Configure WSJT-X

Open WSJT-X settings. Under advanced select "Special operating activities", tick OTP and enter your key from the following details.

Callsign:

OTP Key:

Example:

How it works

LoTW

LoTW uses x509 certificates to sign QSOs. Each QSO is signed using a callsign certificate. To obtain a callsign certificate an operator is required to go through a verification process outlined by the ARRL. FoTW uses the TQSL software to validate that an operator has been verified through this system.

FoTW verification process:

1. Generate a log file for the user to verify
2. The user signs the log file then uploads to us
3. A lambda function extracts the log, obtaining the certificate and signed data
4. It then validates that the log is correct, the signature is matches the log, and that the certificate used to sign the log has been signed by the LoTW
5. The callsign is extract from the certificate, then hashed with a secret. This forms part of the TOTP secret
6. The OTP secret is sent back to the users browser along with the callsign

ToTP Server

The ToTP server is hosted on AWS using CloudFront, API Gateway and Lambda. Effectively the Lambda function is waiting for requests to https://fotw.xyz/check/{callsign}/{timestamp}/{code}

ToTP process:

1. Callsign is converted to uppercase
2. Timestamp is parsed to unix epoch seconds, then divided by 30
3. ".text" is removed from the code
4. The timestamp is checked to ensure its not in the future
5. OTP secret is calculated by hashing a secret with the provided callsign
6. A token is calculated using standard HOTP with the timestamp (remember divided by 30)
7. We compare the provided code and the generated HOTP code - if they match we return back VERIFIED (with no additional bytes on the end such as a new line)
8. If it doesn't match we check 9dx.cc - if they respond we send back their response if no we send back UNVERIFIED

Limitations

• This system requires the user to keep the signed TQ8 file secret / not be tricked into signing a file for someone else. Otherwise a user with access to a signed verification log TQ8 file can request an OTP. Usually sharing TQ8 files wouldn't be a security issue - so this goes against norms a bit.
• There's no self service facility to rotate an OTP key if it was stolen or compromised. This is because there is currently no database in this system. There is facility to do this however it has to be done by hand at this stage. Contact me if this happens.
• This is as secure as LoTW. Which is not very secure. However WSJT-X verification is a low stakes game - so collectively I think we can accept the risk.
• Obviously this requires LoTW to verify users