|
|
|
IntegratorsIntegrate AxiomaticTokenizer in your systems
|
|
|
|
|
|
Integrators of AxiomaticTokenizer can find all the information they need, in here.
Typical integrationAxiomaticTokenizer 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:
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):
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:
Here are the available allowed signature types:
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 serviceYou 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:
AlgorithmsThe 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 32A byte array is normally represented as text in radix 32, using the following character set (confusing characters are not used):
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-SHA256This 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:
The first hash is a SHA256 of following concatenated information:
The second hash is a SHA256 of following concatenated information:
ChecksumA 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 fillingThe 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 stampA time stamp is formed from the following concatenated textual time information, represented in UTC coordinates:
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 tokenThe 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 generationA 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:
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 generationThis 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:
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 generationThis 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):
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 codeThe token integrity code is the textual representation (in radix 32) of the MAC-SHA256 of the following concatenated information:
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 proofsAn 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 MAC's key is the shared secret.
Reference code formatA 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):
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 formatAxiomaticTokenizer 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 exampleAT1; MTM; MP; 20081122115157; aliceakula.pub; bobbonkers.pub; NA; AUG; 10; DET YYM CLR 8G4 SJ5 C9G;
Create accountFields:
This token is always asymmetrically encrypted with the service's public key.
Change passphraseFields:
This token is always asymmetrically encrypted with the service's public key.
Claim compromised accountFields:
This token is always asymmetrically encrypted with the service's public key. See Recover a compromised service for details.
Change service partnerFields:
This token may be unencrypted.
Change sponsored entityFields:
This token may be unencrypted.
Change payment delayFields:
This token may be unencrypted.
Change inheritance trigger timeframeFields:
This token may be unencrypted.
Change show payment historyFields:
This token may be unencrypted.
Add inheritorFields:
This token may be unencrypted. See Inheritors for details.
Remove inheritorFields:
This token may be unencrypted. See Inheritors for details.
Login accountFields:
This token may be unencrypted.
Make paymentFields:
This token may be unencrypted.
Setup subscriptionFields:
This token may be unencrypted. See Subscriptions for details.
Change admin actionsFields:
This token may be unencrypted.
Stop serviceFields:
This token may be unencrypted.
Restart serviceFields:
This token may be unencrypted.
Lock serviceFields:
This token may be unencrypted.
Unlock serviceFields:
This token may be unencrypted.
Lock accountFields:
This token may be unencrypted.
Unlock accountFields:
This token may be unencrypted.
Lock increase balanceFields:
This token may be unencrypted.
Unlock increase balanceFields:
This token may be unencrypted.
Increase balanceFields:
This token may be unencrypted.
Decrease balanceFields:
This token may be unencrypted.
Encrypted token formatAn encrypted token has the following fields (separated by the token field separator):
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 formatAxiomaticTokenizer can process signed documents. Here are the available signature types:
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 strengthThe 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.
DatabaseThe 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 seedsAll 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 tipsHere are some tips for service integration.
Service partners and sponsored entitiesThe 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 privacyIn 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 timeFor 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 executionThere 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 protectionIn 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.
AxiomaticKeyGenYou 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 tokensIf 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 detailsHere is an article which includes technical details about the source code of AxiomaticTokenizer.
Dedicated devicesIf you want to make a device dedicated for AxiomaticTokenizer, consider implementing the following:
|
|
|
|
|
|
|
|
|