How DMT Works

A Simple Explanation

by J. Orlin Grabbe

This article gives a simple explanation of how the DMT system works. First, two crucial
crypto tools which enable the anonymous account system to function reliably are
explained in an intuitive, non-mathematical way. This is followed by an explanation of
how the system is used in the ordinary course of business, while preserving anonymity
and banking security.

The four basic functions of the DMT (and the DMT software) can be best understood by
a simple analogy with ordinary banking. 1) You open a bank account by depositing cash.
Then, 2) you make payments by writing checks, and 3) you receive payments by
depositing checks. Finally, 4) you may choose to withdraw money from the commercial
banking system entirely by taking cash out of the account.

In the same way in the DMT system, 1) you open an account by transferring funds into
DMT from the outside (say from an ordinary bank); 2) you use the DMT software to
make payments to others; 3) you use the DMT software to receive payments from others;
4) you may choose to leave the DMT system entirely by transferring money back into the
ordinary non-anonymous banking world.

The key difference between the two systems is that DMT does not know who you are.
You are anonymous. That fact makes the two systems as different as night and day. If
you are anonymous, how does DMT know that a payment from your bank account is
authorized by you—rather than by an imposter and thief? Moreover, if you make a
payment to someone, how do you know that only that person will be able to deposit your
payment—rather than some stranger for whom it's not intended?

Two Simple Crypto Tools

To understand how anonymity works—how it is possible—we have to understand two
basic concepts from cryptography. The first of these is the notion of a one-way function.
The second is the concept of a challenge-response protocol.

One-Way Function: Intuitively, the idea of a one-way function is that it allows you to
go in one direction, but not the opposite direction. You can walk through the exit door,
but it slams shut and locks behind you and you can't go back. Do not back up: severe tire
damage. You can mix these two liquids together, but you can't un-mix them. You can
multiply two numbers together and get 42, but you can't start with 42 and say which two
numbers were multiplied to arrive at the result (was is 2x21, or 3x14, or 6x7, or …).

The one-way function we are interested in for the DMT system is called a hash function.
The hash function crunches a big number into a smaller number. The nature of the hash
function is that given the big number, it's easy to get to the smaller number. But the hash
is one-way: given the smaller number, it is virtually impossible to find the big number
that produced it. (An example of a hash is given in the next section.)

In this case, X2489 proves who he really is by showing he knows the password reserved
for X2489. Of course, this example isn't very impressive. Because now (if not before)
the sentry knows that "Ewige Blumenkraft" is X2489's secret password, so the sentry
can now masquerade as X2489. So also can the person hiding in the bushes who
overheard this exchange.

Here is a better example. Assume X2489 has a public-private key pair. The sentry says:
"Halt! Who goes there!" "It's me, X2489." "Oh, yeah? Well, I just produced a random
number and encrypted it with X2489's public key. Here's the result. Tell me what my
original random number is." So X2489 decrypts the result using his private (secret) key,
and sends the original random number back to the sentry. This proves to the sentry that
X2489 is who he says he is, because he has possession of X2489's private (secret) key.
Yet, at the same time, the sentry never learns what X2489's private key is. The sentry
can't masquerade as X2489. Neither can the person eavesdropping.

Now, let's see how these two crypto mechanisms, the hash function and the challenge-
response protocol, are used in the DMT system.

The Three Roles of the Customer's Account Number

When you open an account at an ordinary commercial bank, you are assigned an account
number. This number is usually fairly short: 0239446651, for example.

In the DMT, account numbers are long. They can be written as a string of 1024 1s and
0s. Or a string of 256 hexadecimal (base 16) numbers. Or about 308 decimal digits. For
example, here is a DMT account number written as 256 hexadecimal digits:

Pretty long, huh? Don't worry. You won't ever have to remember your account number,
or even write it down. Your DMT browser software will create it for you and store it.
When the account number is needed, the software will also read it and transmit it to the
DMT server. You'll just assign a name to each account, such as "Acme Dollar Account",
and that's how you'll distinguish it from another of your accounts, such as "Blue Baby's
Rands."

But the reason for the length of the account number concerns two additional roles the
bank account number plays.

Additional Role 1: The DMT account number gets hashed to generate a claim number.
Remember that a hash function is a one-way function that crunches a big number down
into a smaller number. There are different hash functions. DMT uses one called the
SHA hash function. The SHA hash function produces "small" numbers that are only 40
hexadecimal numbers long. For example, here is the SHA hash of the account number
above:

5D5F03FF82A4A1BA 58E56D5B135054BF 09A77C0B

Given an account number, it is easy to produce the corresponding SHA hash (the claim
number). But given a claim number, it is virtually impossible to create the account
number from whence it came.

When you want someone to pay you at DMT, you will give them a claim number. You
will select one of your accounts, the software will produce a hash of the account number,
and you will copy and paste this number into some secure messaging system that you use
to conduct your business—for example, Dodge City Nym-toNym messages, or
MailVault PGP-encrypted email, or something similar.

Now the presence of such a number is standard business practice anyway. Frequently,
when paying a bill, you have to include an invoice number, or some similar reference
number. The difference for the DMT system is that the claim number determines who
gets the payment. You don't make payments to an identified individual. You make
payments to a claim number.

Anyone can make a payment to one of your claim numbers. But only you can collect the
payment, because only you know the account number from which the claim number was
created. You can easily derive a claim number from an account number. But this path is
one-way: no one given your claim number will be able to create an account number that
corresponds to it. Therefore they can't collect payments intended for you.

The DMT account number is a pre-image of the claim number. To prove that money
paid to a claim number belongs to you, you have to produce its pre-image—namely the
DMT account number from which the claim number was derived.

Additional Role 2: The DMT account number is also a public key. It is the public key
corresponding to a public-private key pair. This enables it to be used in a challenge-response
protocol.

Don't misunderstand the use of the word "public" here. This public key, your DMT
account number, is never given or shown to anyone. Rather, it is only stored on your
computer by the DMT browser, and is also stored on the DMT server. But, for example,
the DMT server could encrypt something to the DMT browser (such as a random
number) using the customer's public key, and only the customer would be able to decrypt
it. The private (secret) key corresponding to the public key (DMT account number) is
known only to the customer.

As illustration, here is the private key corresponding to the public key (account number)
above:

5DBCA9A911BDA5C8 6288FA2575E95057 C4FBA1D4.

In order to be able to collect a payment made to a claim number, it is not sufficient just to
be able to show the pre-image (the account number) from which the claim number came.
It is also necessary to prove knowledge of the private key corresponding to the account
number (the account number being a public key).

So, after the DMT server verifies that your account number corresponds to the claim
number, it next issues a challenge—a number calculated using both a random number and
your public key. In order to answer this challenge properly, your browser will have to
use your private (secret) key to make the calculation. When it is asked to do this, it will
ask you for your passphrase, which is required to decrypt the private (secret) key for this
account.

Having two separate "proof" mechanisms that one is the proper recipient of a payment
gives the system confidence that it is dealing with the real McCoy, and not with an
imposter. But there is a separate reason for having two mechanisms. The first proof
involves your showing you have the pre-image (the account number) from which the
claim number came. This proof (the account number) is something written down—a
number stored on your hard drive. It is possible someone could get access to your hard
drive and steal this account number. But they still wouldn't be able to use it to collect
your payments because they wouldn't know your private (secret) key. That's because the
private key is protected by a separate layer of encryption, and you have to enter a
passphrase to get access to your private key when you answer the challenge-response
protocol. The private key is decrypted in computer memory just long enough to respond
to the challenge-response protocol. Then it is erased, leaving only the well-encrypted
version. But the passphrase is stored in your head. So a thief would have to rob both
your hard drive and your head to be able to make transactions in your DMT account.

"Little Nicky" Scarfo

DMT customers are moral, honest citizens. But it is useful to tell the following story,
because it shows what a well-financed organization can do when it targets an individual.
It illustrates how your privacy could be broken, including your DMT privacy, if you
allow certain things to happen.

When I lived in Philadelphia, I lived at Society Hill Towers, down near Penn's Landing.
My apartment was in the North Tower, and from my apartment windows I could see the
apartment windows of Nicky Scarfo Jr. who lived in the West Tower. He, in fact, lived
two floors directly above one of my Wharton colleagues.

Nicky Scarfo Jr. was the son of "Little Nicky" Scarfo, who was reputed to be
Philadelphia's leading Mafioso. I don't know if that was true or not—I never observed
either father or son doing anything illegal. But one night Nicky Scarfo Jr. was having
dinner at Dante & Luigi's, a small Italian restaurant south of South Street. A professional
hit man came in and shot him five times. I say the shooter was professional, because
after shooting Nicky Jr., he calmly walked out, dropping the gun. The gun bore no
fingerprints and was not traceable. In another sense the shooter wasn't professional: he
failed to kill Nicky Jr. But the incident left little doubt the family was not your average
South Philly family. (The joke around Philadelphia went: "Want Italian food? Make a
reservation at Dante & Luigi. Be sure to ask for the No-Shooting section.")

So Nicky Jr. survived—and recently became the victim of FBI black bag jobs. Nicky Jr.
had gone on to set up a gambling business in North Jersey. The FBI broke into Nicky
Jr.'s office and stole his computer files which held the financial records of his operation.
But there was a problem. The files were PGP-encrypted. The FBI couldn't read them.
So they got a court order to allow them to install a keystroke logger on Nicky Jr.'s
computer. (You can see a copy of the request to seal this court order here:
http://www.epic.org/crypto/breakin/application.pdf.
It is an Adobe Acrobat .pdf file.)

Now a keystroke logger records all keystrokes that a person makes on his computer.
Eventually, over the course of a day or several days, one will type in one's passwords and
passphrases. These will be recorded in the log file of all keystrokes. There are different
types of keystroke loggers. Some are small programs on the hard drive, so someone has
to return to collect the log file—unless they can do so over the Internet. Other keystroke
loggers might attach to a computer cable; or they might take the form of frequency bugs
installed in the keyboard itself—ones which transmit the keystrokes to a nearby receiving
station. Here is an advertisement for a keystroke logger that attaches to a keyboard cable:
http://www.codexdatasystems.com/keykatch.html.

So the well-financed FBI, making the world safe for democracy, broke in and stole Nicky
Jr.'s computer files; then they broke in again and installed a keystroke logger to steal his
passwords and passphrases. (Read the following article from the Philadelphia Inquirer
for further information about the case:
http://inq.philly.com/content/inquirer/2000/12/04/front_page/JMOB04.htm.)

The lesson is: If you want to keep private information private, then don't allow people to
have access to your computer files; and beware of keystroke loggers that can record your
passwords and passphrases. And if you keep all your records on the same computer,
move it around from time to time.

DMT Signatures

As we noted previously, a hash function (in particular the SHA hash function) is one
example of a one-way function. It crunches a big number down into a small number.
You can go in one direction, but not the other. Such a hash function is used to verify that
account information has not been altered at the customer's browser. When DMT signs an
account, a hash is made of the account balance, the account number, and a random
number. This hash is used along with the DMT's private (secret) key to create a bank
signature.

If anyone alters your account balance or account number, the wrong hash will be
obtained, and the signature will not verify. Moreover, an attempt to create a valid bank
signature will fail because it requires DMT's private (secret) key, which corresponds to
the DMT public key. Finally, and in addition, any altered data will not correspond to the
data at the server.

For example, suppose we have the following bits of financial data:

Account Balance: $5000. This number is the same as 1388 in hexadecimal.

Then the bank signatures on the data would be, first, the random number just given
above, and also the number

8459A92761A569C3 CD5B72139DF81FDA 82F2077F.

Change any of the input numbers, such as the account balance, and this number will not
verify.

How Your DMT Data Is Protected

The Browser Database: Each browser is protected by a password. Entering the correct
password gives you access to your accounts and account data. When a transaction is
initiated with the server, the server verifies that the browser is a DMT browser.

Receiving Payments: When a transaction is made with the server to claim a payment,
the browser must show the proper account number corresponding to a claim number, and
then must also respond to a challenge by using the private (secret) key corresponding to
that account number. In responding to the challenge, the user must enter a passphrase to
decrypt the secret key. Then the same account is decrypted at the server, and the same
financial information verified by comparison with the server information. If all these
tests are successfully passed, then the payment is added to the account balance, and the
new balance is stored on the browser, along with bank signatures corresponding to the
new amount. The new account balance is also recorded by the server.

Making Payments: When a transaction is made with the server to make a payment, a
claim number to which the payment is to be made must be entered. The server then
checks the DMT signatures on the account and verifies that these correspond to the
account number and account balance. The server next sends a challenge to the browser,
which must be responded to by using the private key (again, protected by a passphrase)
corresponding to the account number. Then the same account is decrypted at the server,
and the same financial information verified by comparison with the server information.
If all these tests are successfully passed, then the payment is deducted from the account
balance, and the new balance is stored on the browser, along with bank signatures
corresponding to the new amount. The new account balance is also recorded by the
server.

Communication with the Server: When data is sent from the browser to the server, a
hash is made of some of the key variables in the data, and some key variables are also
encrypted at this point.

Next, the variables are diced into packets for sending to the server. These packets are
encrypted under the TLS protocol (refer to the DMT-faq
for an explanation) and sent to
the server. The server checks each received packet to see that it hasn't been altered in
transit. It then decrypts the packets and obtains the underlying variables (some of these
still in encrypted form). It then decrypts the encrypted variables. Next it makes a hash of
some of the key variables, and compares this to the hash made by the browser. All of this
ensures that the data at the server is the same as the data in the browser.

The Server Network: DMT servers communicate with each other over the Internet,
using an encrypted protocol which creates a Virtual Private Network. (See the
DMT-faq
for further information.) In addition to software security, the servers have physical
security. The server locations are housed in guarded, shielded, fortified facilities, with
power provided by at least two independent power grids, along with backup battery
power and gasoline generators.

Four Simple Financial Transactions

You have money sitting in a bank. A record exists for this money. You know you have
it, the bank knows you have it, and so does anyone else that your bank gives the
information to.

If the money is honestly yours, then it is still honest money when you write a check to
someone, or send a wire transfer to someone, out of that account balance. Either a check
or a wire transfer will create a transaction record. Neither attracts more, nor less,
attention than the other—although a wire transfer is typically harder to trace. But it is
your money, it was honestly obtained, and there is nothing to explain or justify to anyone
when you write a check or make a wire transfer from your account, including a wire
transfer to one of the entities that provide services on behalf of DMT. [We will assume
wire transfers here: other payment mechanisms will be available at a later date.]

Once the money is in the DMT system, transactions become anonymous. No one,
including DMT, can see who collected the money transferred into the system. No one
can see payments and receipts that take place within the system. You have financial
privacy. In the event money emerges from the system, it will appear again in some
non-anonymous bank account just as before.

Transferring Money into the DMT System: Like any payment, money transferred into
the DMT system must be paid to a claim number. So, to transfer money into DMT, you
must use the browser to warn DMT of the coming transfer. You must specify the
currency, the amount, and the claim number. The DMT server will then give you wire
transfer instructions. These instructions will not include the claim number, but will
instead use a reference number that is suitable for wire transfers. This reference number
allows different outside payments to be made to the same claim number, without any
outside observer knowing that payments are going to a common place, because all
reference numbers will differ—whether paid to the same or different claim numbers.

Receiving Payments: Again, as explained previously, the person you are doing
business with will supply you with a claim number. You will tell the browser the currency
and amount of transfer, and the claim number the payment is to be made to. The server will
check to see you know your account passphrase (for whichever account you are making the
payment from), will check the bank signatures, and will update your account balance.

Transferring Money Out of the DMT System: In this case, you will need to give the
DMT server instructions where to wire the money, and the account from which the
money is to be withdrawn. The server will check to see if you know the passphrase
corresponding to the account, and will check the bank signatures. It will then update
your account balance, and wire the money to your designated destination.

Will the browser be easy to use? DMT thinks so. We have 9- and 13-year-old girls using
and testing it now.