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

ATKeyGen

Source code details

Dedicated devices



AxiomaticTokenizer

Emoney


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, send your information to integrate it 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, Change 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

Data is usually hashed only after it's put in a data frame meant to ensure that it's not feasible to find a hash collision.

This MAC is the SHA256 of following concatenated information:

  • Left seed.

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

  • Middle seed.

  • The MAC's key, in uppercase.

  • Right seed.



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.

For all the actions affected by group authentication, all the tokens of the members of the group (present in the token submission form) must be stored. Also, the stored time stamp is the biggest one from the stored tokens.



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.



Change inheritor

Fields:

  • Token version.

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

  • Action identifier: "CI".

  • 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. If this is 0, the inheritor account has to be deleted from the user's account.

  • 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.

A sign document has the following format:

  • The "********** Begin AxiomaticTokenizer Document **********" marker which delimits the beginning of the signed document.

  • The signed text.

  • The "------------------- Begin signature -------------------" marker which delimits the beginning of the signature of the document.

  • "Version=[?];". The version of the signed document.

  • "Type=[?];". The type of the signature.

  • "FFA=[?];". This is the name of the algorithm which is used to generate file fingerprints. For now, only the SHA256 MAC is supported.

  • "ServiceName=[?];". The name of the service which created the signed document.

  • "ServiceSeed=[?];". The seed of the service which created the signed document.

  • "KeyId=[?];". The ID of the asymmetric signing key which was used to sign the document.

  • "Time=[?];". The time when the document was signed.

  • "Salt=[?];". A salt used to randomize the signature.

  • "TextSize=[?];". The size of the signed text.

  • "Value=[?]". The signature value, as a hexadecimal text.

  • The "*********** End AxiomaticTokenizer Document ***********" marker which delimits the end of the signed document.

The "[?]" placeholder can be replaced with any text.

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".

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

  • Year, 4 digits.

  • Month, 2 digits.

  • Day of month, 2 digits.

  • Dash.

  • Hour, 2 digits.

  • Minute, 2 digits.

  • Second, 2 digits.

You can use AxiomaticTokenizerKeyGen to sign documents.



Example

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

AEB 00F 2B4 25A DD2 F15 A77 83B 060 553 D23 25C 623 7A7 AA8 5A6 ED9 BA3 FFD E60 ABF B

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

Version=1;

Type=Authenticate AxiomaticTokenizer;

FFA=AtkSha256;

ServiceName=AxiomaticTokenizer;

ServiceSeed=CO6OS5PKPS57N948OV5J;

KeyId=S1;

Time=20081226-132653;

Salt=C8F 5CF E3F 62C 0D2 CA0 B6;

TextSize=85;

Value=01B A5E 3F3 E76 8D2 BCE C92 E0F BA9 CAF 59C 7A9 80D 91F 9B7 0AF 35F 045 5A8 C51 85A 64D D9D 30C 748 25E 63D 425 9E8 377 ACA E2A 6CE FFA 269 69C 09C 1FD E47 B24 8B2 C97 1A9 CB3 67A FCD C82 2FF B68 23E A17 144 AF2 366 0DA DF2 706 480 A92 498 D44 06B F63 67E 9CC 3E9 8CB 804 652 00B 073 030 40F 6C1 8E7 6CE 79A 717 D6B EBC 15A 918 845 425 5E8 20E 352 835 897 FB7 F1A 646 FC1 603 82B 856 BEB E6A E90 A45 94F E64 8C1 83A A72 E9F 5EA C7B 098 A40 1B4 CDF 41C 381 995 BBE E5E A7D 874 5DF 0B4 6BC 80D 00E E23 14E EC9 01E 74A 1F9 47B F62 BEF 957 868 028 0A6 F18 B2F 78E 5FA 431 CB8 1D8 851 D32 CEB 755 CA6 FAA 20C BAD 71D 2BC 721 C84 CEA EE7 F71 6B3 7B8 0E7 ADC A7D 5A1 531 149 54C DDC 0BA 0D;

*********** 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 Vela 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 Vela 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.



AxiomaticTokenizerKeyGen

You can use "AxiomaticTokenizerKeyGen" to generate identities, generate file fingerprints, decrypt and sign data.

It is available only as source code.

AxiomaticTokenizerKeyGen uses the Vela core.

Don't use this program in production environments.



Usage

Before you can sign documents and decrypt encrypted tokens, you have to create a service initializer (see the "Work \ Create service initializer" menu).

Open AxiomaticTokenizer in a text editor and search the array with service informations ("var ServiceInfos").

In this array, either add your own service information element or edit an existing one.

Use the "Work \ Clip encryption public key M" to copy to the clipboard the data which you have to paste in the "AsymmEncryptionKey.PublicM" field from the service information element.

Use the "Work \ Clip signing public key M" to copy to the clipboard the data which you have to paste in the "AsymmSigningKey.PublicM" field from the service information element.

Set the "ServiceName", "ServiceSeed", "AsymmEncryptionKey.Id", "AsymmSigningKey.Id" fields from the service information element with the same values that you typed when you created the service initializer.

Save the edited file with AxiomaticTokenizer and open it in a webbrowser.



Decrypt encrypted tokens

In AxiomaticTokenizer choose the service whose information you just edited in AxiomaticTokenizer and create an encrypted token.

Copy this token (actually just the token field which contains the encrypted data, the longest one) from the clipboard and in AxiomaticTokenizerKeyGen click on the "Decrypt from clipboard" button. The decrypted token will be put in the visible edit-box.



Verify signatures

In AxiomaticTokenizerKeyGen type some text in the visible edit-box.

Choose the appropriate signature type (just leave it with the default value).

Click on the "Sign to clipboard" button in order to sign the typed text and copy it to the clipboard.

Go to AxiomaticTokenizer's help and then click on the "Verify document signature" link. Now click on the "here" link.

Paste the clipboard content in the visible edit-box and click on the "Process document" button. Follow the wizard until the end.



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.







License | Contact