Integrators

Integrate AxiomaticTokenizer in your systems




Home



Typical integration

Adding a service

Algorithms

Architecture

Reference code format

Token format

Encrypted token format

Signed document format

Weaknesses

Choosing seeds

Integration tips

AxiomaticKeyGen

Source code details

Dedicated devices



AxiomaticTokenizer

GRIC

Emoney

AxiomaticId


Integrators of AxiomaticTokenizer can find all the information they need, in here.



Typical integration

AxiomaticTokenizer is only the client side, the user interface. An online payment service has to implement the server side, that is, code which parses the incoming tokens and executes the requested actions in the database.

Once your service accepts tokens compatible with this standard, contact me to integrate your information in AxiomaticTokenzier.

There is no guarantee that your information will be integrated, no guarantee for how much time it will be in, and also no guarantee for the price of integration (but for the moment it's free).

You have to send the following information:

  • Does the service information have to be visible to the user?

  • Service name, like "Metal Money". This must have at least 3 characters and must be unique.

  • Service seed. This must have at least 20 random characters, must be unique, and may never be changed.

  • Service ID, like "MTM" (for "Metal Money"). The service ID should be short because all tokens include it, and the user has to type it. This must have at least 3 characters and must be unique.

  • The date from which the information is valid. This has the same format as a time stamp, but must contain only the date (not the clock).

  • The weblinks where the user can find the forms where tokens may be typed and submitted to the service for processing. There is more than one weblink in order to mitigate DDOS attacks.

  • The newest version for processable tokens.

  • Accepted service actions. See the available actions below.

  • Does the service have support for service partners? See Service partners for details.

  • Does the service have support for sponsored entities? See Sponsored entities for details.

  • Does the service have support for payment delay? See Payment delay for details.

  • Does the service have support for inheritance? See Inheritors for details.

  • Does the service have support for group authentication? See Group authentication for details.

  • Does the service have support for arbiters? See Arbiters for details.

  • Must tokens always be sent encrypted to the service? (If yes, the tokens can be sent through unencrypted communication channels without any worry about losing privacy, but are much longer and difficult to type.)

  • The number of characters from the token integrity code field which are included in the token, and compared on the service's side. If this is less than 18, the entire code is used. This is used only for unencrypted tokens, to reduce their size.

  • Accepted currency names. See the available names below.

  • Asymmetric encryption key. This is used to encrypt the tokens which are to be sent to the service. See the required fields below.

  • Asymmetric signing key. This is used to verify various signatures created by the service. The encryption and signing keys must be different. See the required fields below.

  • Allowed signature types. See the available types below.

  • Service fingerprint version.

  • Service fingerprint.

Here are the available service actions: Create account, Change passphrase, Claim compromised account., Change service partner, Change sponsored entity, Change payment delay, Change inheritance trigger timeframe, Change show payment history, Add inheritor, Remove inheritor, Login account, Make payment, Setup subscription.

You must implement the following actions in your system (all other actions are optional):

  • Create account.

  • Change passphrase.

  • Claim compromised account. The implementation of this action may be delayed until it's necessary.

  • Login account.

  • Make payment.

Here are the available service administration actions: Change admin actions, Stop service, Restart service, Lock service, Unlock service, Lock account, Unlock account, Lock increase balance, Unlock increase balance, Increase balance, Decrease balance.

Implementing service administration actions is optional.

Here are the available currency names: Gold gram (AUG), Gold ounce (AUO), Silver gram (AGG), Silver ounce (AGO), Australian Dollar (AUD), British Pound (GBP), Canadian Dollar (CAD), Chinese Yuan (CNY), Euro (EUR), Japanese Yen (JPY), New Zealand Dollar (NZD), Swiss Franc (CHF), US Dollar (USD). Other currency names can be added.

An asymmetric key has the following required fields:

  • Key identifier, like "E1".

  • RSA public key exponent, like "10001". Must be a hexadecimal string.

  • RSA public key modulus; this must have at least 2048 bits. Must be a hexadecimal string.

Here are the available allowed signature types:

  • Authentication. This is automatically used if it's necessary.

  • Authenticate AxiomaticTokenizer.

  • Import self service info. This is automatically used if it's necessary.

  • Import any service info.

Root service information, used only by AxiomaticTokenizer to verify signatures (not to create tokens), doesn't need token submission weblinks, service actions, currency names, asymmetric encryption key.

If a given service validity date is present multiple times in the array with service information, the service name / seed / ID must be different for all those array items.

If a given service name is present multiple times in the array with service information, the service seed must be the same for all those array items.

If a given service seed is present multiple times in the array with service information, the service name must be the same for all those array items.

If a given service ID is present multiple times in the array with service information, the service seed must be the same for all those array items.

If a given service name is present multiple times in the array with service information, the array item with the validity date closest (and older) than the current date is used.



Adding a service

You can easily add a new service to AxiomaticTokenizer.

Open the source code in a text editor and search for the following text: "var ServiceInfos". This variable is an array which contains the information for all supported services.

Copy one of the existing service elements, as a new service element, and change its information. Pay special attention to:

  • "ServiceName".

  • "ServiceSeed".

  • "ServiceId".

  • "TokenSubmitFormWeblinks".

  • "AsymmEncryptionKey".

  • "AsymmSigningKey".

  • "ServiceFingerprint".



Algorithms

The used algorithms are hashes (SHA256), MACs (MAC-SHA256), asymmetric encryption (RSA).

Pseudo-random number generators and symmetric encryption have been specifically excluded from the design of AxiomaticTokenizer.



Radix 32

A byte array is normally represented as text in radix 32, using the following character set (confusing characters are not used):

  • "0123456789ABCDEFGHJKLMNPRSTUVXYZ".

The first character from the text corresponds to the least significant 5 bits of the byte array, and so on.

Encrypted tokens are represented as text in radix 16 for simpler interoperability (because it has to be reversed by services).



MAC-SHA256

This MAC is computed using two keys derived from the shared secret, using two SHA256 hashes. One key is called inner key, one outer key.

The inner and the outer keys are the SHA256 of following concatenated information:

  • MAC inner / outer key seed.

  • The key (with which the MAC is computed).

The first hash is a SHA256 of following concatenated information:

  • Inner key.

  • The SHA256 of the message (for which the MAC is computed).

The second hash is a SHA256 of following concatenated information:

  • Outer key.

  • The first hash.



Checksum

A checksum provides assurance that a text is not typed erroneously by a user.

A checksum version "1" is made of the first 2 characters of the textual representation (in radix 32) of the SHA256 of the text for which it is computed.



Architecture



Texts and data filling

The letter case for all texts (like names and passphrases) is insensitive. During comparisons and hashing, all text is converted to upper case.

All texts are encoded in ASCII-7.

A token is formed by several fields, each two being separated by a token field separator: ";". A token always ends with a token field separator. This separator is not included in any data to hash.

Long texts are always displayed in motes of 3 characters with a mote separator (= a blank space) among them. This separator is not included in any data to hash.



Time stamp

A time stamp is formed from the following concatenated textual time information, represented in UTC coordinates:

  • Year, 4 digits.

  • Month, 2 digits.

  • Day of month, 2 digits.

  • Hour, 2 digits.

  • Minute, 2 digits.

  • Second, 2 digits.

The time stamp makes it possible for the service to not store the tokens, and not have to compare a token which is being executed with the previously executed tokens.



Last successfully executed token

The last successfully executed token must be stored, for each account, by the service in order to know when to send back to the user the "LastExecuted" execution proof. When a new token is successfully executed, the previous one must be overwritten (it may still exist in the history).

The time stamp of the last successfully executed token must be stored, for each account, by the service in order to know that the future tokens with a time stamp smaller or equal with it are not to be executed.

In the case of group authentication, the stored time stamp is the biggest one from all the tokens received in the same token submit form.



Shared secret generation

A shared secret is the textual representation (in radix 32) of a passphrase blender.

The passphrase blender version "1" applies SHA256 20 times iteratively (= over the previous binary hash), to the MAC-SHA256 of following concatenated information:

  • Passphrase blender seed.

  • Service seed.

  • User account locator.

The MAC's key is the user passphrase.

This algorithm allows the user to use the same passphrase for all services because the shared secret is different for each of them (and no service can retrieve the user's passphrase).



Service fingerprint generation

This is executed for the "Generate service fingerprint" service action.

A service fingerprint version "1" is made of the first 25 characters of the textual representation (in radix 32) of the SHA256 of following concatenated information:

  • Service fingerprint seed.

  • Concatenated service information size (the text from the next bullet).

  • All the concatenated service information, in textual form, each piece of information separated by a "|" character. The service actions and currency names are concatenated in the same way.

If the service fingerprint generated by your AxiomaticTokenizer is the same as the service fingerprint published by the service itself or by an entity you trust, or by one of your friends, you can be sure that the service information used to generate your tokens is correct.



Account locator generation

This is executed for the "Generate account locator" service action.

An account locator version "1" is made of the first 12 characters of the textual representation (in radix 32) of the MAC-SHA256 of the following concatenated information (of the token):

  • Account name blender seed.

  • Service seed.

The MAC's key is the user account name.

This algorithm allows the user to use the same account name for all services, without the two services being able to link the accounts to the same user, because the account locator is different for each of them.



Token integrity code

The token integrity code is the textual representation (in radix 32) of the MAC-SHA256 of the following concatenated information:

  • Token integrity code seed (for the current token version).

  • All the token fields (without the token field separators) concatenated together.

The MAC's key is the shared secret. For "Create account" tokens, since there is no existing shared secret, the new shared secret is used instead.

For "Create account" tokens, since there is no existing shared secret to guarantee authenticity, the token integrity code is computed because it ensures that there is no (accidental) corruption of the token.

Depending on the service, if the token is not encrypted, only the first X characters (minimum 18) of the token integrity code are used.



Execution proofs

An execution proof version "AT1" is made of the first 15 characters of the textual representation (in radix 32) of the MAC-SHA256 of the following concatenated information (of the token):

  • The seed of the type of execution proof.

  • The token fields which are used to generate the token integrity code (without the token field separators).

The MAC's key is the shared secret.



Reference code format

A reference code is displayed for all tokens. A reference code has the same version as the associated token.

A reference code version "AT1" is made of the first 15 characters of the textual representation (in radix 32) of the MAC-SHA256 of the following concatenated information (of the token):

  • Reference code seed (for the current token version).

  • All the token fields (without the token field separators) concatenated together.

The MAC's key is the shared secret.

A token reference code is computed by both the user's AxiomaticTokenizer and by the service.

When an action has a recipient, the service must store the reference code in the recipient's account history, together with the token data.

In the case of a client making a payment to a store, since a reference code can be computed only by the client who generated the token, and by the service, and since the online store also has it in his account's history, the reference code can be used as a mild proof that a person claiming to have made a payment is indeed the client. The word "mild" is used here because this works only as long as the reference code is kept secret by the three parties.

If you need to quickly locate a token long after it is generated, keep the token reference code.



Token format

AxiomaticTokenizer implements tokens specifically to be used for a payment service.

A token is formed by several fields, each two being separated by a token field separator: ";". This is not included in the data to hash.

A token may contain white spaces. These must be removed before the token is processed.



Payment token example

AT1; MTM; MP; 20081122115157; aliceakula.pub; bobbonkers.pub; NA; AUG; 10; DET YYM CLR 8G4 SJ5 C9G;



Create account

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CA".

  • Time stamp.

  • Generator application identifier.

  • The account locator of the user.

  • The account locator of the service partner which is associated to the user's account. If the user didn't specify a service partner, this field contains "NSP".

  • The account locator of the sponsored entity which is associated to the user's account. If the user didn't specify a sponsored entity, this field contains "NSE".

  • Payment delay. If the user didn't specify a payment delay, this field contains "NPD".

  • Inheritance trigger timeframe.

  • Show payment history. This is "SH" if the history has to be shown, and "HH" if it has to be hidden.

  • Group authentication. This field contains two numbers: the first is the required number of present members, the second is the total number of members of the group.

  • The textual representation of the new shared secret.

  • The token integrity code.

This token is always asymmetrically encrypted with the service's public key.



Change passphrase

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CP".

  • Time stamp.

  • The account locator of the user.

  • The textual representation of the new shared secret. The new shared secret may not be the same as the old one.

  • The token integrity code.

This token is always asymmetrically encrypted with the service's public key.



Claim compromised account

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CCA".

  • Time stamp.

  • The account locator of the user.

  • The textual representation of the pre-hash of the current shared secret.

  • The textual representation of the new shared secret. The new shared secret may not be the same as the old one.

  • The token integrity code.

This token is always asymmetrically encrypted with the service's public key.

See Recover a compromised service for details.



Change service partner

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CSP".

  • Time stamp.

  • Generator application identifier.

  • The account locator of the user.

  • The account locator of the service partner which is associated to the user's account. If the user didn't specify a service partner, this field contains "NSP".

  • The token integrity code.

This token may be unencrypted.



Change sponsored entity

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CSE".

  • Time stamp.

  • Generator application identifier.

  • The account locator of the user.

  • The account locator of the sponsored entity which is associated to the user's account. If the user didn't specify a sponsored entity, this field contains "NSE".

  • The token integrity code.

This token may be unencrypted.



Change payment delay

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CPD".

  • Time stamp.

  • Generator application identifier.

  • The account locator of the user.

  • Payment delay. If the user didn't specify a payment delay, this field contains "NPD". For security reasons, once the payment delay is set, it can only be increased (not decreased).

  • The token integrity code.

This token may be unencrypted.



Change inheritance trigger timeframe

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CITT".

  • Time stamp.

  • Generator application identifier.

  • The account locator of the user.

  • Inheritance trigger timeframe.

  • The token integrity code.

This token may be unencrypted.



Change show payment history

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CSPH".

  • Time stamp.

  • Generator application identifier.

  • The account locator of the user.

  • Show payment history. This is "SH" if the history has to be shown, and "HH" if it has to be hidden.

  • The token integrity code.

This token may be unencrypted.



Add inheritor

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "AI".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the inheritance.

  • The number of inheritance shares received by the recipient account.

  • The token integrity code.

This token may be unencrypted.

See Inheritors for details.



Remove inheritor

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "RI".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the inheritance.

  • The token integrity code.

This token may be unencrypted.

See Inheritors for details.



Login account

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "LA".

  • Time stamp.

  • The account locator of the user.

  • The token integrity code.

This token may be unencrypted.



Make payment

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "MP".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the payment.

  • The account locator of the arbiter of the payment. If the user didn't specify an arbiter, this field contains "NA".

  • The name of the currency to be paid.

  • The amount of currency to be paid.

  • The token integrity code.

This token may be unencrypted.



Setup subscription

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "SS".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the payment.

  • The name of the currency to be paid.

  • The amount of currency to be paid.

  • The timeframe between two consecutive payments.

  • The number of times to make the payment.

  • The token integrity code.

This token may be unencrypted.

See Subscriptions for details.



Change admin actions

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "CAA_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the new administrative actions.

  • The identifiers of the new administrative actions, separated by a comma.

  • The token integrity code.

This token may be unencrypted.



Stop service

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "SS_AA".

  • Time stamp.

  • The account locator of the user.

  • The token integrity code.

This token may be unencrypted.



Restart service

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "RS_AA".

  • Time stamp.

  • The account locator of the user.

  • The token integrity code.

This token may be unencrypted.



Lock service

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "LS_AA".

  • Time stamp.

  • The account locator of the user.

  • The token integrity code.

This token may be unencrypted.



Unlock service

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "US_AA".

  • Time stamp.

  • The account locator of the user.

  • The token integrity code.

This token may be unencrypted.



Lock account

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "LA_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the account to be locked.

  • The token integrity code.

This token may be unencrypted.



Unlock account

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "UA_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the account to be unlocked.

  • The token integrity code.

This token may be unencrypted.



Lock increase balance

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "LIB_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the account whose balance may no longer be increased.

  • The token integrity code.

This token may be unencrypted.



Unlock increase balance

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "UIB_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the account whose balance may be increased from now on.

  • The token integrity code.

This token may be unencrypted.



Increase balance

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "IB_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the modified balance.

  • The amount of account units with which the balance has to be increased.

  • The token integrity code.

This token may be unencrypted.



Decrease balance

Fields:

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Action identifier: "DB_AA".

  • Time stamp.

  • The account locator of the user.

  • The account locator of the recipient of the modified balance.

  • The amount of account units with which the balance has to be decreased.

  • The token integrity code.

This token may be unencrypted.



Encrypted token format

An encrypted token has the following fields (separated by the token field separator):

  • Token version.

  • Service ID. This allows tokens to be processed automatically.

  • Service public key identifier.

  • Encrypted data.

A service must expect to receive a token either encrypted or unencrypted. A token is encrypted if it has exactly 4 fields; the third field is the service's public key identifier.

The RSA padding is PKCS#1 v1.5.



Signed document format

AxiomaticTokenizer can process signed documents.

Here are the available signature types:

  • Authentication.

  • Authenticate AxiomaticTokenizer.

  • Import self service info. This doesn't allow the imported service information to have the "Import any service info" allowed signature type.

  • Import any service info.

Any unknown signature type is treated as "Authentication".



Example

********** Begin AxiomaticTokenizer Document **********

SHA256 file fingerprint: E5D 47A 36B 887 5EA 1F1 BD4 9F0 738 D7E 5A4 EE6 C5B 2F2 8EF AEB 371 8C2 B0C 2EB B36 A

------------------- Begin signature -------------------

Version=1;

Type=Authenticate AxiomaticTokenizer;

ServiceName=AxiomaticTokenizer;

ServiceSeed=CO6OS5PKPS57N948OV5J;

KeyId=S1;

Time=20081122-145845;

Salt=B7E 80E AC8 2DB 08A 6CD 24B CB2 710 AF4 ACE 0B0 38B 9;

TextSize=110;

Value=1AF 06A 3AF 224 9FB E80 338 7D9 CA2 10B 11C 306 C2A B54 331 1FC 7C2 238 E37 7B7 119 EBF 4CA B0A 3AE 4B1 E54 C47 60D 3B7 B1C 39B 5C1 8EC 267 059 BA9 E9E 075 1DE 85A 2C6 296 9CD 4B8 AC4 1C5 A5B A64 748 633 001 ECB AFD B5A FCD 3E1 A25 6BE 98D 37D 7EE 259 5C8 92B ABD CA5 A77 7B2 9EC B1D F0B 5A5 722 B68 1FF 60A 83B F17 906 8E3 B42 633 634 54C 89E 941 17A C4C 36C F03 4C4 35D BA0 F72 773 464 981 D26 119 655 806 202 EB1 425 7DF 786 DE9 833 3C1 FA8 C6B 9FE 2DC 297 D30 BB7 DE9 FEA CFA A3B 27F 521 6FE 306 96A 191 D32 E9B EB9 70B 5AC 366 8DC 13C 8B3 338 2DC 9B4 E2C 1BE 401 D9F FD7 035 15B E7F E55 CF0 40E 44F 413 90B C49 8A9 427 6EB 7A4 8D7 65F E8E 018 78E E73 526 52A 3B2 593 56E 973 BA;

*********** End AxiomaticTokenizer Document ***********



Weaknesses



Passphrase strength

The security of all tokens depends on how strong the user's passphrase is and on whether a thief can intercept an unencrypted token.

If the passphrase is weak, like a single word, a thief who can intercept a token can use all the known data to initiate a dictionary attack until he finds that a certain passphrase generates the token.

Due to the fact that AxiomaticTokenizer is written in JavaScript and because iterative hashes written in JavaScript are thousands of times slower than iterative hashes written in native code (C), very few hash iterations are used when the shared secret is generated from the user's passphrase. This makes a dictionary attack much easier.

Therefore, it's critical to use a strong passphrase, as is specified in the documentation of AxiomaticTokenizer, made from a memorized part and a written part. Of course, someone might easily get the written part of the passphrase, but this is virtually impossible to do remotely. The memorized part makes the written part useless on its own.



Database

The service must store the shared secrets as they are given by the users. It's not possible to hash them as passwords are hashed because the shared secret is not sent by the user every time he requests an action to be executed.

This means that a thief who can read the (decrypted) database can steal all the digital currency from all accounts, but clearly this is the last problem the service has.

A service can recover from such an event. See this for details.



Choosing seeds

All the seeds (like those for the passphrase and account name blenders) used by the cryptographic algorithms of AxiomaticTokenizer in order to make it difficult for an attacker to precompute the shared secrets associated to user passphrases, and the account locators associated to account names, are randomly chosen.

Each character from a seed is obtained by rolling two dice and then looking that up in the dice-character mappings table from the AxiomaticTokenizer's help.

However, as this standard becomes more widely used, when a new blender version is created with a new seed, people might fear that the chosen seed was selected with enough time before its publication in order to allow precomputation.

Therefore, a seed must be chosen through a public process, with little time before the new blender version is made public. Practically, a number of prominent organizations with an online presence have to be requested by the AxiomaticId Entity to choose several characters which would be part of the new seed.

Each such organization has to simply roll two dice several times, and use the dice-character mappings table from the AxiomaticTokenizer's help to generate the necessary seed characters. These characters have to be published on the websites of these organizations, for everyone to see.

Then, the AxiomaticId Entity has to form the new seed by simply concatenating all the published characters.



Integration tips

Here are some tips for service integration.



Service partners and sponsored entities

The implementation of service partners and sponsored entities must not hamper the distributive capabilities of the database.

For this to happen, the fees for the service partners must not be added to their accounts at the same time the payments are made.

Instead, they must be added to a special table and consolidated only once a day / week, either automatically or manually by the service partners.



User privacy

In order to protect the privacy of the users, care must be taken.

The service partners and sponsored entities must not know what users have added them to their accounts, and how much and who do they pay.

Users must not know who added them as inheritors.



Token time

For increased safety, a service should consider invalid a token whose time stamp is smaller with more than 7 days than the current (service) time, or bigger with more than 5 minutes (this margin of error is for cases when clocks are desynchronized).



Multiple token execution

There is no need to verify the entire history of tokens in order to ensure that a token is executed only one time, so long as the time stamp of the token is verified to be bigger (not equal) than the time stamp of the last successfully executed token (time stamp which is stored for each account).



Brute force protection

In order to deter brute force attacks against an account, a service must process less than 10 ^ 13 tokens / second / account, be it serial or parallel processing, while returning "Invalid token integrity code" to the user.

This provides safety for the shortest token integrity codes for several decades.



AxiomaticKeyGen

You can use AxiomaticKeyGen to generate asymmetric keys, decrypt and sign data, and generate file fingerprints.

You can also look at the source code to see how to decrypt the encrypted tokens using C#.



Verify encrypted tokens

If you want to see an unencrypted token which was encrypted by AxiomaticTokenizer, first use the "Generate RSA key" function from AxiomaticKeyGen to generate an RSA key.

Copy the "M" key parameter into AxiomaticTokenizer, as the public key of the service for which you generate the token, for example as the value of the "MetalMoney_RsaPublicKeyM" variable. There is no need to set the "E" key parameter, the default value is the same for both applications.

Generate an encrypted token for the service.

Copy the token, just the token field which contains the encrypted data (= the longest one), and paste it in the "To decrypt" text-box from AxiomaticKeyGen. The white spaces are irrelevant.

Click the "RSA decrypt" button, in AxiomaticKeyGen.

In the "To encrypt" text-box, you can see the unencrypted token.



Source code details

Here is an article which includes technical details about the source code of AxiomaticTokenizer.



Dedicated devices

If you want to make a device dedicated for AxiomaticTokenizer, consider implementing the following:

  • No rewritable permanent memory. There is no need for any kind of data to be permanently stored.

  • Wipe the RAM on device reboot. This deletes any sensitive data which is still in the RAM.

  • The JavaScript host should implement a function (named "WipeFreeRam") to wipe the free RAM; a garbage collection must be performed first. This function should take less than 3 seconds to complete.

  • When the device is about to enter in standby mode, the JavaScript host should call the "WipeSensitiveData" function from AxiomaticTokenizer.







Copyright by George Hara