What is this for?

If you need to use an RSA SecurID software token to generate one-time passwords, and have been given an activation code and a URL like https://XXX.com:443/ctkip/services/CtkipService, this software will allow you to provision the token and save it in a format that you can use with stoken.

If you use the RSA's official software (RSA SecurID) to provision the token, it will obscure the token seed to prevent you from copying it to another computer:

Requirements

Client needs Python 3.x, PyCryptoDome, and requests (which will be automatically installed with pip). stoken is needed to save the resulting tokens in a usable format. Running the fake server requires Flask as well.

Install with pip3 to automatically fetch Python dependencies. (Note that on most systems, pip invokes the Python 2.x version, while pip3 invokes the Python 3.x version.)

# Install latest development version
$ pip3 install https://github.com/dlenski/rsa_ct_kip/archive/HEAD.zip

# Install a tagged release
# (replace "RELEASE" with one of the tag/release version numbers on the "Releases" page)
$ pip3 install https://github.com/dlenski/rsa_ct_kip/archive/v0.3.zip

Provision token using client

Provide the client with the activation URL and activation code (usually 12 digits), and a file in which to save the token file. It will communicate with the RSA CT-KIP server and provision a token, then attempt to call stoken to convert the token to XML/.sdtid format:

$ rsa_ct_kip https://server.company.com:443/ctkip/services/CtkipService ACTIVATION_CODE /tmp/test.sdtid
Sending ClientHello request to server...
Received ServerHello response with server nonce (R_S = 28198dbe2c18a00335179cc5bb4eff3a) and 1024-bit RSA public key
Generated client nonce (R_C = 12bec1a6f4d09470986b485561c4d2b5)
Sending ServerFinished request to server, with encrypted client nonce...
MAC verified (0f103bc63a8819ffdbee657d042144f6)
Received ServerFinished response with token information:
  Service ID: RSA CT-KIP
  Key ID: 838999658504
  Token ID: 838999658504
  Token User:
  Expiration date: 2020-01-23T00:00:00+00:00
  OTP mode: 8 Decimal, every 60 seconds
  Token seed: 30ade1be20b3867d967bd2927c8eb0ca
Saved token in XML/.sdtid format to /tmp/test.sdtid

If stoken is not installed in your path, or fails to execute successfully, then a template file will be left behind instead. Convert the template output to an RSA SecurID token in XML format with a working copy of stoken, as instructed:

$ stoken export --random --sdtid --template=template.xml > 838999658504.sdtid

Fake server

The server (invoked with python3 -m rsa_ct_kip.fakeserver) mimics a "real" RSA CT-KIP server and can be used for interoperability testing with a "real" RSA SecurID client. It accepts the requests sent by the client software at two different paths: / for laziness, and /ctkip/services/CtkipService in case any real client hard-codes this path.

It provisions tokens with randomly-generated 12-digit IDs, which it does not retain. Official RSA SecurID clients for Windows and Android have been verified to connect to it, and provision tokens from its output.

The server can run either via HTTP or HTTPS. For HTTPS, create a server.pem file in the same directory. It must contain a trusted, signed certificate in order for the RSA SecurID app to connect to it.

The package also includes rsaprivkey.pem, used by the fake server. This the RSA private key used for token generation, and shouldn't need to be modified for testing purposes. (The one included is a 1024-bit key with modulus 65537, similar to what seem to be used by the "real" RSA CT-KIP server).

Protocol

The protocol used here is allegedly documented in the RFC4758 "draft standard". There are numerous problems with this protocol:

• The draft RFC is convoluted, overly-complex, and unclear. It's obviously an attempt to describe the operation of an existing program rather than to design a useful protocol.
• The only "existing implementations" are in RSA's closed-source software. I use scare quotes because the actual implementations use algorithms that differ in several ways, making it impossible to interoperate without reverse-engineering.
• The exchange is wrapped in several unnecessary layers of base64+XML+SOAP terribleness… but the official RSA clients don't really parse XML: they just pretend to, and get confused by whitespace differences and similar trivialities.
• The protocol appears to be trying to solve the following problem, "How can a client and server agree on a long-term key (the token secret) in such a way that if the exchange is MITMed, they can't arrive at the same long-term key?" There are numerous things that make this scheme impractical and confusing and unmaintable, but the icing on the cake is that the official clients don't even give a usefully distinctive error message when they are being MITMed.

Dear RSA: This is one of the most insanely idiotic protocols I have ever seen. At no point in its rambling, incoherent design is it even close to serving a rational purpose. Everyone involved in reverse engineering it is now dumber for having studied it. I award you no points, and may God have mercy on your souls.

Credits

• @cemeyer for kicking this off and doing most of the heavy lifting, including figuring out all the mistakes in RSA's atrociously sloppy and misleading RFC4758, writing a bug-for-bug matching ct_kip_prf_aes implementation based on it, and even submitting IETF errata.
• @rgerganov for reverse engineering the official client and testing.
• @cernekee for writing stoken in the first place, and for explaining how to convert a raw seed into a token.
• Future time traveler who travels back to 2006, and convinces RSA that they are objectively bad at designing protocols and should never do it for any reason whatsoever.

TODO

• Convert raw seed into usable token without invoking stoken?
• Better test_full_exchange: verify that when client.py talks to fakeserver.py, they negotiate the same K_TOKEN.

License

MIT