Support v4 tokens

[kayrus]

I have a token that starts with com.rsa.securid://ctf?ctfData=BAEBB...
It is protected by password and I suppose it is encrypted, that is why I received the:

error: --token string is garbled: General failure

If I decode the token using base64 and then analyze the hex, token starts with the following hex data: 04 01 01 07... It is definitely new version of token.

Is there any public resource about v3 and v4 spec? Or does this task require reverse engineering?

[bmassif]

Hi,

I have the same problem, my token starts with com.rsa.securid://ctf?ctfData=BAEBz1...
I also got a password to install it.

When I try to import it in stoken I get
error: --token string is garbled: General failure
I don't know how much work it would take but it would be nice to be able to import these token into stoken.

[cernekee]

In order to figure out the v3 token format I had to look at how RSA's TokenConverter handled them. I wasn't able to find a public specification. You could start off with an XML file from stoken export --random --sdtid and ask TokenConverter to convert it into different CTF formats.

Not sure if the latest TokenConverter supports the v4 format, however. It doesn't look like it's been updated in a while.

[esskar]

any progress on this?
@birou007 @kayrus any chance that you are able to provide an old/expired token that could be used to reverse engineer?

[widgetii]

@esskar I have an expired v4 token and can share it

com.rsa.securid://ctf?ctfData=BAABaKfqKwgEkWDGEgaxp2ZGloQ7dDw2A8PglNlhP8qCBhtop%2BorCASRYMYSBrGnZkaWhDt0PDYDw%2BCU2WE%2FyoIGGznAfd6pVLcjsDtpKoG5APTUrXL51Bdnf%2FCDvZanmNEGhzDCbsDsFTFyLgKzdht0X1tKt23tFwP%2FDYg9xDS1HvS8Jy3QfT04PFNm%2BdCUUZyMIoTzdFT01msNHtrRxePWU7cB32CE48U%2BKlbW4hPyhphJhkg5qxUA38cD05J1s44hI3FTjaq%2FAhAKAQWsDy7TZE6qtU5f6cYIzdr5PKILhTyCeXRxiYuLinAkXEHWm%2F%2FrFKyroQpn%2FVYAA3NLS59HWBQwWyS2kzhtlzJh%2BI25IMhdhLvVdXdjuNzRxkwjc74z

No password locked, but device locked, Device ID d82c467c56fb2058edf8add6

It seems that v4 format is very close to v3 one, especially it has same token size of 291 bytes. First of all I supposed that it has same fields in storage structure, adjusted sources and used v3 code to decrypt v4 seed. It passed checks in v3_compute_hash(NULL, devid, t->v3->nonce, hash); and v3_compute_hash(pass, devid, t->v3->nonce, hash); (comparing nonce_devid_hash and nonce_devid_pass_hash, but stucked at v3_compute_hmac(t->v3, pass, devid, hash). It calculates hmac and compares it with token's mac and finds inequality.

[widgetii]

Here is my patch for basic v4 tokens decode support
#51