Good morning.
Welcome to the last session of Algorithms for Internet Applications.
It's actually the really last session, because this is the last
lecture that I will give.
And so, last time we have looked into electronic payment systems.
After we have finished the part on cryptography, then we looked at
digital signatures and things like that.
Now we look at applications of cryptographic algorithms.
I think I should briefly change the light.
So, there we are back.
We looked at electronic payment systems.
I started to tell you something about that.
We looked at different levels of electronic payment systems.
I showed you that there are three different variants.
There are two-party, three-party open loop systems.
I briefly explained to you how they look like, depending on the number
of participants in those scenarios.
And the example was university students and shops.
And you would like to get, as a student, you would like to get
services.
And the university gives stored values.
And this is just an example which you can replace with customers and
bank and shops and whatever.
And the major problem, if you have an open loop system, is that you
have to prevent double spending.
Since it is simple to copy an electronic document, if you have an
electronic document which represents a coin, you must make sure that
you cannot double spend an amount of money that you have actually got
in your electronic wallet.
And so, we have to look at all kinds of evaluation criteria for
electronic payment systems.
And so, these were security, transaction costs, accountability,
traceability.
I told you something about online checking requirements, which have to
do with making sure that the value that you actually would like to
spend actually is valid.
And this refers not only to open loop payment systems, but also, for
example, to using bank cards.
You know that there are different systems.
Either you provide a signature or you provide a PIN and then it is
checked online with a bank whether that bank card actually is valid.
And then you have the acceptance of payment systems.
Also, acceptability is an important point.
Usability, transferability is also important.
Divisibility, you would like to represent any amount.
You cannot do that with real cash.
You can only have amounts of money which you can combine from the
coins that you have available.
But if you have online currency, you can't represent any real value as
some value of payment.
Then there are credit card systems.
If we go to credit card systems, there are risks associated with
credit card systems.
Let's go back to this here.
There are several different payment protocols for credit cards.
You know them because you all use, I guess, credit cards.
So let's just look at a few of those.
First of all, the risks.
What kind of risks do we actually have?
A customer wants to order some goods or services on the internet and
wants to pay with a credit card.
And then you get this form back from the server.
And there you have a few lines you have to enter.
You have to enter the number of your credit card.
You have to enter your name, the validity period or expiry date.
And usually you have also to provide another special value which is on
the reverse side of the credit card.
And then you send all that.
So you have to get that.
That HTML document asks for information.
And then this is transferred back to the server.
So what are the attacks?
The attacker just eavesdrops the datagrams with all credit card
information.
Gets all that information from the internet.
Assuming that it is not safely encrypted.
That it's sent in plain text.
And nowadays we know it should all be done over a secure channel.
But if it's not done over a secure channel, you send all that.
The attacker modifies the HTML document.
Like somehow manages to modify the document that is sent to you as a
customer.
And then manages to get a copy of that information.
And so all the information is sent to some third parties.
To some man or woman in the middle.
Now, this is an attack where you could say, oh, this is really
something which is dangerous.
Because if I want to make a purchase with my credit card, all I have
to provide is the number.
And all these numbers.
Expiry date.
And usually my signature.
Here what you get is just credit card numbers and names.
You don't get a signature.
There are other situations where actually you get everything.
If you pay at a, let's say, gas station.
You buy something with your credit card.
You sign.
And the slip is handed over to the cashier.
And then they have everything.
They have the number.
They have all the numbers.
They have the signature.
And a contract to buy something with a credit card needs these
numbers.
Or this credit card number and a signature.
So it's essentially much more dangerous to provide on a piece of paper
the credit card number and your signature.
Because that can be used for other purposes.
Over the internet you just provide your name and a credit card number.
Which is not sufficient to actually legally establish a contract that
you have to pay for something.
So the risk is much higher if you write something on a paper slip and
hand it over to somebody.
Because then they have everything.
They even have your signature.
Which they can't copy for other purposes.
So it's not that with the internet these risks are much higher.
But certainly they are.
Because since it is difficult to actually put in your signature it
would be possible.
But this is not done.
Payments are based just on the credit card number and all this other
information and the name.
Then this is not completely safe.
But it is taken as a possibility for a merchant to get his money and
the credit card company actually pays.
If you protest against that then it has to be reversed.
Because it's not a legal contract.
So you have to be aware of that.
But it doesn't help.
We know that we would like to pay with a credit card and so we need
secure ways of doing that.
So ways of protection.
Use of authentication.
Digital signature.
Certainly encryption.
And certainly this is done using secure channels.
And I will just briefly give you a very high level view into what this
secure channel, this typical secure channel is about.
This has actually nothing to do with credit card payments.
It just has to do with having a secure channel.
And so what we normally have is our sender and receiver.
We have all these ports.
And then here we have TCP which is providing a connection.
Now we would like to make that secure.
And to make that secure, to make that not vulnerable for
eavesdropping.
So we have to encrypt everything.
And this has been designed by several companies.
Netscape did that together with some other people.
Meanwhile, it's no longer the secure socket layer but transport layer
security which is the follow-up standard.
Afterwards, it has been around for quite some time.
Meanwhile, it provides authentication, digital signatures and
encryption of documents.
And this is above TCP IP.
So here we have TCP as you know.
And here we have TLS above that.
That's immediately above TCP.
And then all the applications then would go through TLS.
And here again we have TLS.
And then through TLS you get into your application again.
So everything that is on this line here will be encrypted.
But everything above that is still in plain text.
So the applications don't see anything in encrypted form.
The applications see it in plain text.
And only the transmission line below TCP everything is done in
encrypted way.
So this is some security but the security is only on the transmission
line.
And it's not above that.
So it uses the standard protocols.
It uses standard cryptographic algorithms.
So there are the typical asymmetric and symmetric methods in there.
Essentially the protocol that I showed you at the end of the chapter
on cryptographic algorithms.
And then in order to know what kind of algorithms are available.
Usually there is a handshake protocol which I will show you on the
next slide in a high level way.
I will show you that they actually have to agree upon the methods that
have to be used.
And depending on what is available on both sides of the connection.
And then everything above this layer can switch essentially to a
secure channel.
So for example HTTP which is a service on top of that.
So HTTP can select to use TLS for communication.
Then TLS, TCP and so on.
And then so HTTP is transformed into HTTPS.
Because then SSL or TLS is used for the TCP connection.
And so you have encryption on that line.
But you don't have encryption on top of that.
This is something which you have to be aware of.
So if an attacker gets into the application layer.
And puts some application and communicates with the other
applications.
Or just replaces an application that is using or that is actually
providing the information.
Which is supposed to go in a secure way over the TCP line.
Then this replaced application gets all the information.
There is nothing protected.
The protection is only on the TCP line and not above that.
This is an important point.
If you want to get real security from application to application.
The application has to take care of the security.
And it should not transfer that to a layer below that.
And so the transport layer is just below.
And so TLS will hide certain things.
But as I said, the application layer is not protected.
What does this protocol look like?
In a very simplified way.
Just shows that some information has to be sent around here.
The client wants to establish a connection with some server.
Wants to get some information.
And for that the cryptographic capabilities have to be sent.
And some random number for, you know, like Diffie-Hellman key
exchange.
Some information was exchanged.
The server responds with his hello.
Like server hello means the server provides some information.
Some standard attributes.
Cryptographic methods or method that is chosen depending on what the
client has actually provided as information.
What kind of cryptographic methods can be used.
Then the certificate has to be provided.
So the certificate with the public key of the server.
Certificate request has also to be sent.
So the server needs a certificate, needs a public key from the client.
And also a random number again.
Then the certificate is sent by the client.
And some information encoded with the server's public key.
Which was extracted from that certificate.
And then the server will send back some information which was
generated from the pre-master key.
Similar to what you have seen in the Diffie-Hellman protocol.
Where things are sent in two ways back and forth between the two
communication partners.
And so in this way they can generate the master key.
So a key for communicating.
They can generate the same master key which they will use actually for
communication afterwards.
The same is done on the client side.
And then they can encrypt the data that is sent between the two
partners.
Using that master key.
So they use a symmetric method for encrypting the contents of the data
that is sent back and forth.
And they also needed some other methods actually to generate that
master key.
Needed some kind of public key cryptosystem for that.
And this is indicated here.
I don't want to go into the details.
I provided you with all the ingredients in the chapter on
cryptography.
So you need the system for key exchange.
Diffie-Hellman for example can be used here.
But they have to agree on the system that they actually use.
Which kind of method for generation of a standard or master key for
the symmetric encryption.
And then when they have generated that in a secure way, they can
communicate.
So this is done every time we open up an SSL connection.
Every time we have an HTTPS connection, we have that communication.
But this is just the standard protocol.
Certainly done in a sophisticated way.
Specified, as I said, in the appropriate RFC.
You can look that up.
Okay, don't go into the details.
I would like to go into more details in another protocol which was
designed specifically for making the application credit card payments
more secure.
And I present that not because it is one of the standard ways of
communicating information between the actors in credit card payments.
But because it is a very interesting protocol, having another
interesting concept in there.
The concept of a dual signature.
And this is an interesting concept.
I would like to present you that concept.
And this goes a little bit beyond what we have seen as the standard
secure communication protocol which I showed you at the end of the
chapter on cryptography.
So, what are the requirements for the secure electronic transactions?
The requirements are, first of all, that you would like to have
confidentiality.
Not everything should be known.
But what should be known to whom and what should not be known?
What should be hidden?
So, we need confidentiality with respect to the payment event and to
the purchase order.
So, the payment event, like our bank credentials and so on and the
banking information, should only be known to the bank.
Not to the shop owner.
The shop owner should know what kind of thing I would like to buy.
But the bank need not know that.
The bank only needs a request from the merchant that he needs some
money.
And so, in some way, these two things have to be separated.
You have the payment information and you have the purchase order.
And these have different addressees.
One is the merchant, the other one is the bank.
And so, this has to be dealt with in an appropriate way.
And so, this is done by appropriate method using different signatures
in a nice way.
And you also need authentication of merchant and customer.
The merchant would like to know whether the customer actually has a
valid credit card or valid payment information.
It's not really essential that it is a credit card.
It's just essential that the customer can provide information on how
he would like to pay for what he would like to purchase.
And the merchant certainly should also be checked whether he is
authorized to accept credit cards or authorized to actually get that
money.
Whether that will be done in an appropriate way.
So, there needs to be some communication between the customer and the
bank to make sure that the money will be transferred in an appropriate
way.
And these requirements are met by that protocol and I will show you
how that is working.
So, we have three actors here.
We have the customer, we have the merchant and we have the bank.
Black on blue is always a bad thing.
You should never do that if you use colors in your presentations.
Black on blue is bad.
But originally it was not that dark blue.
Somehow it changed from PowerPoint version to PowerPoint version.
But, nevertheless.
So, on blue you usually use yellow or white as a color for writing.
Okay, what do they do?
The customer would like to buy something at the merchant.
He contacts the merchant.
The merchant answers or initiates answers to that request.
We have a typical request response protocol.
I will show you all these ingredients there in a moment.
And then the customer would like to buy something.
He sends a purchase order.
The merchant sends some response.
And at the same time he sends an information or a request to the bank
to check whether the bank will actually allow that payment process.
And so the bank will respond to that.
Will check the validity of that payment information.
Then the customer may ask whether that actually has been done.
The merchant will respond to that.
And so the purchase is carried out.
And then the merchant would like to get the money.
And he sends a payment capture request to the bank.
And then will get a payment capture response from the bank.
And we will go through all these, not all, but most of these
communications and see how that actually is achieved using all the
ingredients we have seen in the previous chapter.
And some new ideas.
First of all, one thing is different from what we have seen.
Here we have two public key pairs.
That means we have one public key pair for digital signatures.
We know why we need it there.
So just for integrity checking, we have one public key pair.
And then there is another public key pair for sending session keys.
So session keys are, as you know, keys for encrypting information.
And these keys should be used only once.
So we have the random key has to be encrypted.
But the recipient has to be able to get that key.
So we need asymmetric or we need public key pair for encrypting the
session key.
And for security reasons, this is separated.
One key for digital signatures.
One key pair for session keys.
And certainly the public keys are verified using some kind of
certification hierarchy.
Using some route of trust as we have looked at.
And then the purchase order has the following form.
We have the customer message to the merchant.
This has to be visible to the merchant.
Definitely.
We have the customer message to the bank.
This has to be visible for the bank.
But not for the merchant.
It's of no interest to the merchant.
The merchant only needs to know where he should send that, which bank
he should send that to.
That's the payment information.
The other was the order information.
And then we generate two different signatures.
Not signatures, but digests.
Using some message digest method, some hash method.
As we have seen, there are several different possibilities for that.
So we have two message digests.
One for the order information.
One for the payment information.
And then we combine both.
We generate a digest of those two digests.
Now this digest of digests is combined information on the two parts,
the order information and the payment information.
And then this is signed by the customer's private key.
That's the signature.
It's a dual signature, because it's at the same time a signature of
the order information and a signature of the payment information.
It is a combined signature, a dual signature.
And now, as I said, the merchant should not get access to the payment
information.
This should be encrypted.
So the customer message to the bank is encrypted using a session key.
And the bank's public key for key exchange.
So he needs that.
The customer must know what is the bank's public key for key exchange.
And so he encrypts this message with a session key.
The session key is encrypted using the bank's public key.
Then the merchant will not be able to open that payment information,
because the bank does not have the bank's private key exchange key.
So the bank can only forward that information to the bank, but doesn't
get access to that information.
So the merchant can read only his part of the message, only the order
information.
That's all that he needs.
And the encrypted payment information, the dual signature, and the
hidden session key are forwarded to the bank.
And then the bank has all the information about the necessary payment,
but doesn't get information about what the customer actually has
purchased, or wants to purchase, or has ordered.
So this is the highest level of confidentiality that you can get here.
The stakeholders there only get the information that they need to
perform that transaction, or the transaction they are responsible for.
And this has to do with providing only the information that you need
for a certain decision, and not more.
Payment information is hidden from the merchant, order information is
hidden from the bank.
Those are the two important points.
You can imagine that something like that is a little bit complex.
So it is a quite expensive piece of software if you install that.
So it was expensive, and people did not actually install that.
So the SCT protocol did not get into widespread use, although it has
many advantages, but the main advantage is with the customer.
The main advantage is not with the bank, is not with the merchant.
Because if they get all the information, they can make or generate
extra money from that, if they have more information.
If they know what the customer has bought, the bank can actually do
all kinds of things with that information.
So there is no interest from the side of the bank or the merchant to
hide all that information.
The major interest is with the customer.
And so this is the reason why it did not get into widespread use, but
it is a very interesting concept, and I will show you a little bit
more about that.
So this is, again, this communication scheme.
First of all, the cardholder initiates a request, sends that to the
merchant.
The merchant will send certificates about the bank he communicates
with, and so on.
It will send that to the cardholder, will be looked at there, then the
purchase request is compiled, and the merchant will respond to that.
And this will be shown in more detail.
A few of these things will be shown in more detail.
The first simple part of that is the response of the merchant to the
initial request of the customer.
What does the customer need?
So first of all, the merchant has to respond in some way, so that's
the initiate response, or the response to the initiation of that
communication.
And that is hashed into this message digest, and the message digest
then is encrypted using the merchant's private signature key.
Digital signature, for that he has a public key pair for the
signatures.
And then you have a digital signature of that response.
Now this is one part which has to be sent, this is not encrypted, this
is just sent in plain text, but you have a digital signature that
allows you to check the integrity later on of that text that is in the
response there.
What else do you need?
You need the merchant certificate signature key, that's for allowing
the cardholder, the customer, to verify that this digital signature
here, or that this message is correct.
So he needs the public key in order to be able to decrypt the digital
signature.
And he needs the payment gateway's certificate for the key exchange
key, because he wants to provide the payment information in encrypted
form, for that he has to send the session key with the public key of
the payment gateway, so the merchant sends the public key of the
payment gateway.
That is sent to the cardholder, now the cardholder just extracts all
the information, he can, using the same hash function, can generate a
message digest of that initiate response message here.
He can decrypt the digital signature using the public key of the
merchant, and then gets the message digest, can compare, that's what
we know, the standard communication, and then he will compile his
purchase order.
Now this complex thing is generated, he writes up the order
information, he writes up the payment information.
Both are hashed into the message digest for the order information and
for the payment information, both are hashed into the combined message
digest, the order and payment information message digest.
And this is signed, that means the cardholder's private signature key
is used to get that dual signature.
Now the payment information and the dual signature actually, the dual
signature from there, both are encrypted using some random symmetric
key, session key.
So you have the encrypted payment message, this is something which the
merchant will have to forward to the payment gateway.
And the payment information message digest this year is also forwarded
to the merchant, plus certainly the order information and the dual
signature, and then the payment gateway needs the session key.
So this session key, this symmetric key here, plus the account data
are encrypted using the payment gateway's public key exchange key.
So it's not only the key which is forwarded in a digital envelope to
the merchant, not the session key, but also the account data, both are
necessary for the payment gateway to actually process then that
payment information.
And the cardholder has to send his certificate for his public
signature key, because he has provided that dual signature in order to
check that the public key is needed.
This is sent to the merchant.
So this is the essential part, the order information, the payment
information, the dual signature.
Now what can the merchant do with that?
The merchant does not get access to this encrypted payment message.
Now he has to verify whether the signature actually was correct, or
the information he gets is correct.
He has the order information.
From the order information he can generate a digest to check whether
something has gone wrong in between.
Now he has to, in order to check whether the dual signature, which he
can decrypt using the cardholder's public key, yes, so he gets here
the combined message digest.
He can generate the combined message digest from the generated order
information and the payment information message digest, which was sent
by the cardholder.
He can generate this combined message digest and check whether the
generated combined message digest is the same as the decrypted
combined message digest.
So this here, this part was generated by the cardholder, this part was
generated by the merchant, based on the document that he received.
Since he cannot access the payment information, he cannot generate the
payment information digest on his side, so he needs that digest.
And he can then generate the combined message digest and check whether
they coincide.
He's doing an integrity check, and this integrity check is then
showing whether the order information was correct, and he hopes that
the payment information is adequate.
He only gets the payment information message digest.
And then he has to send on, like he sends a purchase response, this is
not really of interest, and the customer will answer to that, this is
also not really of interest.
The next interesting point is how the merchant communicates with the
payment gateway.
So he has to send an authorization request, and the bank has to
respond to that.
How is this done?
The merchant has to send information to the payment gateway in order
to make sure that he gets his money.
So he sends an authorization request, which again is provided with the
message digest, and then this is encrypted using the merchant's
private signature key.
He has to sign that request.
And then they get a digital signature for the request.
Actually, this time the authorization request and the digital
signature are both encrypted using a session key.
This is a session key generated by the merchant, and so the merchant
will also encrypt this symmetric key using the payment gateway's
public key.
Then you have here this digital envelope for the symmetric key for the
encrypted authorization request.
And in this authorization request there will be private information of
the merchant about his bank details, his account data, and so on.
Because he has to make a statement to the bank of what kind of money
he needs, where that has to be sent to, and so on.
So this is private information, therefore it has to be encrypted, must
be sent in a confidential way.
The order information before was not that private, was not encrypted,
could have been encrypted, but that was not done in that protocol.
And then what else do they have to send?
He certainly also has to send the encrypted payment message and the
payment digital envelope that he received from the customer.
This now has to be forwarded to the bank.
And in addition to that, he has to forward three certificates.
Certificate of the cardholder on his public key, because this is the
signature key.
The cardholder has signed his payment information.
This has to be checked by the bank.
The merchant has to send his signature, or his public key, because he
has provided a signature.
This has to be checked.
So the bank needs, or the payment gateway needs the public key.
And the merchant has to send another public key.
He has to send the key exchange key, because later on the payment
gateway will send encrypted information to the merchant.
And for that, the bank needs the merchant's public key.
Okay, the gateway now is extracting all the information.
He gets the authorization request from the merchant.
He has a digital envelope.
He has to decrypt that using a symmetric key.
The symmetric key is retrieved from that digital envelope using the
payment gateway's private key exchange key.
He gets the symmetric key that is used to decrypt the encrypted
authorization request.
And then this authorization request is decrypted.
A digest is generated.
The digital signature, which was also in that encrypted authorization
request, this digital signature, is decrypted using the merchant's
public signature key.
Here there was the certificate down there, so the payment gateway gets
the public signature key from the bank.
And then the message digest is decrypted.
Both are compared and checked for validity.
Another integrity check.
Now down here we have the part that belongs to the payment information
initially constructed by the customer.
How does the payment gateway get the information from the customer?
The bank would like to decrypt that information.
For that it needs the symmetric key.
The symmetric key is retrieved from the payment digital envelope by
using the payment gateway's private key.
It was encrypted using the payment gateway's public key, so the
private key can be used to decrypt that.
That leads to the symmetric key that is used to decrypt the payment
message.
Then the payment message is there, the payment information and the
dual signature.
The payment information is then again checked for integrity, so a
payment information message digest is generated.
Now in the authorization request, the merchant had to include also the
order information message digest.
The second part, the bank does not get the order information, but
needs the order information digest in order to combine both into the
combined message digest.
So this is the generated combined message digest on the payment
gateway side.
And the payment gateway will also decrypt the dual signature using the
cardholder's public key, gets the decrypted signature, gets the
combined message digest, can check that for integrity.
So the payment gateway needed for that the payment information, which
was decrypted.
And it also needed the digest of the order information, but it did not
need the complete order information.
And so it could check the validity of the payment information and that
it actually corresponded to the order information that the merchant
has got before.
But the bank does not get information on what things the customer has
ordered.
And so this is showing how we can actually achieve here
confidentiality in the appropriate ways.
And then the cardholder's balance at issuer is checked whether
actually the cardholder's credit card has sufficient validity.
And then the... now it's another very interesting point.
What does the bank or the payment gateway send back to the merchant?
The merchant will not immediately get the payment transfer, but it
will only get so-called capture token.
Now capture token is information that the merchant later on can use to
actually get the amount of money transferred to his account from the
credit card owner's account.
Or from the credit card company.
So this information that the merchant later on will be able to use to
request the actual payment is encrypted using a symmetric key.
And this key is encrypted, and this is interesting, by the payment
gateway's public key exchange key.
So the payment gateway encrypts this information using his own public
key for key exchange.
So the merchant will not be able to decrypt that message, this capture
token message.
Only the payment gateway itself will be able to decrypt that again.
Because it's encrypted using the public key exchange key of the
payment gateway.
So this is a token, which is just some token where the merchant will
not be able to look into.
But later on he will be able to send it again back to the bank, and
then the bank will be able to open it and proceed on that.
What else does the bank send back?
So it got here the authorization response.
Will have some information that this customer is good for actually
initiating that payment.
So all kinds of information the merchant actually needs to make sure
that he can actually process the order.
And so this again has to be signed in the typical way to get a digital
signature of that authorization response.
And then the authorization response together with the digital
signature again is encrypted.
Because there is some private information which should be kept
confidential.
And this is encrypted using a symmetric key which is again put into a
digital envelope.
So with the merchant's public key exchange key.
Then the merchant will be able to open this part.
This is what he needs.
He also needs the capture token, but only later on.
And this is an interesting way of actually sending a response to that
merchant.
He knows from the authorization message that everything is okay, or
whether everything is okay.
And the capture token allows him to later on capture the money.
So this then is... like this is simple.
And then we have the payment transaction, the final payment
transaction, the capture request is sent.
So the capture request, the merchant, now after he has executed that
order, he will send the capture request.
This is the capture token message.
This was encrypted using the payment gateways key, so he cannot access
that, but he can certainly send it back to the bank.
And he has to send some information, a capture request, in the typical
format that is specified in the protocol.
What kind of information he has to provide when he wants to actually
get the payment.
And so he has to compile that, he has to sign that with digital
signature.
He will encrypt that and then put the symmetric key that was used
there again in a digital envelope.
Provide it with the appropriate certificates and send that to the
payment gateway.
And now the payment gateway receives that.
And the payment gateway actually will decrypt the capture message from
the merchant and will also decrypt now the capture token.
Now as the capture token was decrypted using their own symmetric key
that had been encrypted by the payment gateway, its own public key, so
the private key can be used to decrypt that.
The capture token is there, the message is there, this was the capture
request.
And now the payment gateway can actually communicate with the bank,
with the cardholder's financial institution, use the capture token
such that actually this payment is...
So this is actually carried out and then a message is sent back to the
merchant to tell the merchant that everything has been transferred.
So this is the payment capture response message and then this is
telling the merchant that everything has been carried out.
So that was a rather complex protocol.
I think it's interesting for two points, this idea of separating the
information that you would like to exchange into two parts where the
two parts are determined to be readable for the two different
stakeholders, the merchant and the bank, but not by both.
And to make sure that you can check the integrity, not just of the
individual information, but always check also whether it is connected
with the appropriate second part.
So checking the validity, the integrity of the payment information
needed an adequate digest of the order information.
And checking the validity of the order information needed a digest of
the appropriate payment information.
And so this combination was always checked, whether they are combined
in an appropriate way, but the merchant only got his part in plain
text and the bank could decrypt the payment information which the
merchant was not capable to do.
So in this way we have a rather high degree of anonymity which is good
for the customer mainly.
So we as customers should have an interest in actually having that
established, but then we would have to pay for that.
So we have integrity of order information at merchant side can be
checked, the integrity of payment information can be checked, and the
valid combination of order and payment information.
That's the dual signature idea.
And the other point is that we have two separate public key pairs, one
public key pair for the signatures and one public key pair for
exchanging symmetric keys.
Another point.
One could go into arguments why this is actually adding an additional
level of security, but I will not do that.
You can look that up at other places.
And what you have also seen is that in several ways here the standards
protocol which I showed you at the end of the last chapter actually is
integrated into that sophisticated protocol.
And finally the use of capture tokens is also of interest that you
send some information to the merchant, like the payment gateway sends
information to the merchant, which the merchant actually cannot look
into, but can be used to later on capture the payment after the order
has been processed.
So after the merchant actually is justified to actually capture that
money.
So that's the capture token.
Information that you send to a communication partner, encrypted in a
way that only you yourself can decrypt it again, but you provide this
capture token which makes sure it's some kind of assurance to the
merchant that he will get his money.
Okay.
Now there are other ways of doing... of other payment systems which
you could look at.
I will... like you can go to PayPal or whatever, click and buy.
There are different methods of paying with credit cards.
I don't want to go into the details here.
This is not as secure.
Confidentiality is not there to that extent.
And there is a completely different way using online banking,
integrating your online banking capabilities as a customer into a
purchase process.
So you as a customer would like to actually buy something at a
merchant.
And when it comes to the payment step, a window opens up on your
browser and you get your bank's online banking system.
And you can initiate on that window an online fund transfer with your
bank.
You have your home banking system, can initiate an online transaction.
And when that is complete, a message is sent back to the merchant.
So the customer bank transfers the amount to the merchant bank.
And then... so that this is initiated.
And then the information is sent back to the merchant that the amount
of money has been transferred to the merchant's bank.
And then the product that has been bought by the customer can be sent
to the customer.
And in this way, all the information about how to pay actually is
something which is only visible to the customer.
But you need to use your online banking credentials for that.
So another way of doing that, not using credit cards, but using your
typical home banking systems, using TANs and things like that,
whatever you have there.
Okay, you know that there are all kinds of different methods for
payment.
Meanwhile, there are also these methods using smartphones, where you
just get additional credentials over your smartphone.
And you have to put that into the transaction step with your merchant.
I guess you know these things.
I would like to show you another idea, which also is an interesting
algorithmic concept.
So the first algorithmic concept was the dual signature, the capture
tokens.
Now I would like to show you a blind digital signature, which is the
essential part that allows for having some kind of...
It's almost real electronic money.
You will see in what way it is electronic money, this e-cash system.
What is a blind signature?
You know what a blind signature is.
Sometimes you get an envelope and there is a line there and you are
asked to sign.
And there is carbonated paper inside.
And then after you take out that slip, or if you open the envelope,
you can take out a piece of paper and your signature is on it.
But you have not seen what you actually signed, because it was in that
envelope.
This is something which is actually done in some situations.
And this is a so-called blind signature, because one point is missing
in the normal signature process.
Normally we say we look at a document, check the validity, and certify
with our signature that everything is correct.
Here we only get an envelope, put our signature on that envelope and
certify something, the validity of something which is hidden in the
envelope.
And somebody else can take out that piece of paper and has a signature
on some kind of information that was on there, but the person who
signed did not know what was on there.
Strange idea.
But this is a very interesting idea, because we can sign something, we
can validate something, without having all the information about what
you have validated.
And for eCash this is an important point, because it provides
anonymity about the values that you actually need to have certified by
a bank.
You will see how that is working.
So it is a closed loop system, it is not an open loop system, you have
three parties, you have banks, customers and merchants.
The banks will issue the electronic coins, they will change real money
into eCash, so they can transfer money from your account and send you
back eCash coins.
And you can change eCash into real money, this is essentially what I
said, stored values.
What is so important about it?
But the important point is that you need anonymity for that.
So you will see in what sense we get here anonymity.
The customers have an account at an eCash bank, they can withdraw
eCash and they can deposit eCash.
And the merchants will accept eCash and they can certainly also
revalidate that, they can get real money for eCash, I did not put it
on there, exchange eCash into real money.
But this certainly only by going to the bank, so the merchant cannot
exchange that, they will need to go to the bank to change eCash into
real money.
But certainly the merchants must be able to get the money in some way,
so they will have to communicate with the bank to get that.
Ok, how does that work?
How can we generate electronic coins?
The customer software actually is generating the coins.
The customers do not validate the coins, the customer generates random
serial numbers, sufficiently long numbers such that with a very high
probability you get a unique number.
So every customer who does that gets in some way a different random
number, this is something which is assumed.
And then for every serial number you fix the desired coin value.
So you generate a real number and then you say this should be worth 5
euros or 10 cents or 1000 euros, you can put in whatever you like.
Not completely whatever you like, because you have to send the hidden
serial numbers and coin values to the bank.
So this is what I said, you send this envelope to the bank and you ask
for a signature.
The serial number is inside.
The coin value is also written there, it says ok, 5 euros.
Now you send that to the bank and the bank is asked to validate the
coin by its value specific blind signature.
So it's providing a signature, this signature is the specific
signature for validating 5 euro electronic coins.
And then it deducts the corresponding amount from the customer's
account, you have to exchange real money with e-cash and sends the
validated coins back to the customer in that envelope.
And then the customer software extracts the coin and there it says 5
euro, there is the serial number on it and the signature of the bank.
And now you have a coin having a serial number certified by the bank
to carry a certain value.
Now you can use that, this is an electronic coin, it has been
certified by the bank that this piece of information having a unique
random number, this serial number, has a value of 5 euros.
Certified by the bank.
This you can use now to go somewhere and pay.
Certainly you could also make all kinds of copies of that.
Perfect, you just copy that and now you have not just one 5 euro coin,
but you have 1,000 5 euro coins.
Perfect.
But they all have the same serial number.
So the serial number will be used to make sure that you cannot double
spend.
But this is also the drawback of that system which actually results in
a closed loop system and not in an open loop system.
So, again the blind signature, how do we do that?
How do we hide a serial number?
We have the following, or we use the following procedure.
Here we have again Alice and Bob who are communicating and Alice wants
to have Bob sign a message M without knowing M.
So you hide that in this blinding envelope.
What is a blinding envelope?
The blinding envelope in that case is just a random number which Alice
chooses, or the customer in that case is choosing.
A random number which is prime relative to this N, the modulus of your
public key method.
And then you compute M' as R to the C, so C is Bob's public key.
So R to the C times M modulo N.
That's M'.
And M' is sent to Bob.
So Bob does not get M to the C, he does not get M, he does not get M
to the C, but he gets R to the C times M, modulo N.
And now Bob returns his signature of that.
What is his signature?
His signature is encrypting that information with his private key.
His private key is D.
So he takes M' to the D modulo N.
That is using his private key for signing.
Now M' to the D is certainly equal to R to the C times M to the D
modulo N.
Which is R to the C times D times M, which is R times M to the D,
because R to the C times D, as we know, is equal to R.
This is what we had in the RSA algorithm.
And now Alice computes Bob's signature of M.
She just needs to divide that by R to the minus one, so divide it by
R, multiply it by R to the minus one.
And this results in M to the D mod N.
And M to the D mod N, this value U here, is the value that is
encrypted using Bob's private key.
That's what Alice wanted to get.
M signed by Bob, that means M should use his private key to encrypt
it.
Because then you can check whether he actually did it with his private
key by using his public key.
You can check whether it is this message M that he signed.
So you can use that for integrity checking.
So you have a signature.
You have the signature U, and Alice just needed to use that blinding
random value R, which she can use later on to retrieve the signature
of Bob on that message M.
This is a blind signature.
Another nice idea how you can get a signature from the bank.
What does the bank in this case?
We will come back to that in a moment.
In this case here, Bob could generate this signature U of M.
Only Bob could do that because he needed to use his private key.
He did not sign M but M'.
He signed some information which contained a hidden information
inside.
Only Alice can retrieve the signed signature because she knows R.
Only she knows that random value.
And any other person can verify that Bob actually signed that message
or that number M because using Bob's public key you can decrypt that.
And find out whether that is M or not.
And M is in our situation the random serial number of a coin.
And so you get a coin with a serial number.
You can use the signature, this number which was the encrypted value.
You can decrypt that using the public key of Bob or in our situation
the bank.
And check whether it is the same serial number.
Then you know, okay, this was signed by Bob or by the bank.
And so this is the central point, this blind signature.
And again, here that's the situation for the bank.
You have the customer blinds the serial numbers using the method that
I just showed you.
Puts the coins into a digital envelope which he signs with his private
key.
He certainly doesn't send that in plain text but puts that into some
digital envelope.
So he signs that with his private key so the bank can verify that.
The customer sends the hidden coins to the bank encrypted with the
bank's public key.
Only the bank can decrypt that so nobody else can get access to that.
The bank then verifies the customer's signature.
Signs the hidden coins with his private key corresponding to the
requested amount.
And deducts the corresponding amount from the customer's account.
And then the bank returns the validated blinded coins to the customer.
And the customer can use his private key again to decrypt the bank's
message.
Removes the blinding factor and then has a serial number, a signature
and the signing bank's certificate to allow for every recipient of
that coin to check the validity of that coin.
So this here is such an electronic coin.
So in this way the bank does not know which coin it actually has
validated.
It only knows that it has validated an electronic coin of that value.
And that value was deducted from a certain person's account.
And so when that is spent, this electronic coin, or by that customer,
is transferred to somebody else.
And somebody else now brings that or shows that electronic coin to the
bank and would like to get the real value.
The bank will be able to check whether it has actually signed that
coin, whether that is valid.
And then sees, okay, this bank has validated it, so the real money is
transferred to the person who showed this coin.
And then it only knows that for this serial number, now such a
transaction has taken place.
But it does not know who actually provided that electronic coin to the
merchant.
So this is the anonymity that we have with real cash.
If I give you normal cash, you can go with the cash to the bank, and
the bank does not know that I gave you the money.
And this is exactly the point behind e-cash, that you can spend the
money, and the bank later on does not know who actually has spent that
money.
They can only exchange it again into real value.
So if you shop with e-cash, you provide, or there is a payment
request, the customer sends his coins to the merchant.
The merchant knows, okay, accepts e-cash, goes to the e-cash bank,
asks for exchange, and then the verification means that the money is
transferred.
But this invalidates, certainly, the coin.
And this is the problem of that system.
So it's a nice idea of that blind signature, the problem is you can
only use it once.
Because then certainly the e-cash bank will, so you send a receipt for
verification, the bank certainly stores all the serial numbers of
retrieved coins.
Then it knows which coins actually have been exchanged into real money
again.
And when somebody presents an electronic coin with a certain serial
number, the bank will check whether it has already exchanged money on
that serial number.
And so double spending is prevented by using this list of serial
numbers at the bank, then the bank can check that there is no double
spending.
This is the whole idea about e-cash.
But it certainly means if you accept e-cash, and now if you would
transfer that to somebody else, so then the next person does not know
whether that coin is still valid or whether it has been already
exchanged with the bank.
So as I showed you here, this receipt certainly is only sent after the
bank or the merchant got a verification from the bank that this coin
was still valid.
Otherwise you have a risk that this coin might have been invalidated
already.
This is the double spending problem.
Okay, so evaluation of e-cash has rather low transaction costs.
It's secure by typical public key encryption.
Traceability is restricted, we have anonymity of the customer.
The receipt is sent, so there is undeniability of the payment.
The user actually can find out what happened to his coins, because the
user who validated, no, the user who generated the coin, generated the
serial number and can check who actually exchanged that electronic
coin into real money.
So the user can unveil his identity to the bank and say, I actually
originally generated that coin, if he likes to do that for whatever
reason.
But the problem is that online checking is necessary to be sure that
the coin is still valid.
So the question is whether that actually is acceptable.
So transferability is also a problem.
Do I get the real element or a copy of a coin?
And divisibility certainly depends on the coin values that you have
there.
Okay, now I have a problem.
So the next part would be to show you bitcoins, but time is running
out more or less.
We have 10 more minutes.
I wanted to show you a little bit more as some final remarks on this
course.
So bitcoins actually are the online banking method now that is
actually used.
As you know, there are a few essential points in there.
We don't need any central entity.
There is no single point of failure, although for one of those, like
equivalence to bitcoin for Ethereum, there has been one customer, one
participant who used incorrect software, which resulted in a loss of
65 million dollars.
So that you could say, okay, obviously you can as a single attacker
actually attack successfully such a system, and this can lead to a
significant loss of value.
So no single point of failure is not really true.
But there are no financial institutions necessary.
It is a purely peer-to-peer version of electronic cash.
And the verification of transactions is done by a network of people.
They are all verifying the transactions.
And this is based on cryptographic proof rather than on trust.
But the trust is that there will be...
if you have many people who are actually trying to verify certain
transactions, you always rely on the majority.
So you try to get a majority decision whether a certain transaction is
valid or not.
And they all have information about all the transactions that are done
there in the bitcoin system.
And so if the majority verifies that a transaction is valid, they will
notice, since they have information about all the transactions, they
will notice if double spending has occurred, and then they will not
validate the second transaction with the same payment.
With the same value.
So this was very short, but you cannot understand that.
There are certain technical things in there.
There are transactions which are...
the transaction actually is the information about what kind of thing
you are doing in that payment transfer.
And then you have to, again, write signatures on that.
You have to provide public keys.
You have to sign with your private key.
You put in your public key and people can actually verify whether a
sequence of transactions is correct.
And the sequential nature is determined by combining a transaction
with another transaction, but only, like, a hash is generated from a
previous transaction and what you have in this transaction.
So this is a rather complex system.
I don't have the time to go into the details here.
So these are the transactions.
And then you have the so-called blockchain.
And in the blockchain you have a sequence of blocks.
Every block has a certain information.
There you have all kinds of transactions.
And then you have to generate a number which is used only once.
And used only once.
That's the nonce that is here stated.
Now this number has to be chosen such that the information in that
block, which contains also a hash of the previous block, ends up in a
hash value of a certain type.
Here initially you have only zeros.
So the hash value, this hash value here, must have a certain
structure.
And so you look for a collision, a partial collision.
And to generate that partial collision, you have to generate a number
here that, together with all the information you have in the block,
results in a hash value of a certain structure.
And to find that, you have to invest computer time.
It means people have to compute things.
This is the mining in a blockchain.
You have to invest computer time to find out, to find a number which,
together with the information you have here in that block, this is the
number of transactions of those bitcoins, will actually result in an
appropriate hash value.
And you only do that after you have checked the validity of all those
transactions.
And these blocks are combined in this way that you always have the
hash of the previous block in there.
And so now you have block chains, because you generate a new block
with a new number which is used only once.
And then many people are doing that, and they add blocks to those
chains.
And only the longest chain in that structure actually is assumed to be
valid.
Because the longest chain means that more people have actually trusted
a certain...
All these here have trusted this branch here, and not that branch.
This was not continued.
That was not continued.
Only this one was continued, so this is the trustable one.
This is the idea behind block chains.
Now I have to stop with that, so there are several things that have to
be looked at here.
I will have to stop, and you can look it up on the slides that I have
provided you, and you get a little bit more information about
payments.
And that's the end of this chapter.
And I also provide you on our website, or on our storage area, with
actually this chapter on information on using the internet or internet
ideas for energy systems.
This term, I was too slow, or I was not here all the times, and only
once I used the possibility to provide you with a recorded lecture
from previous years.
And we had two or three dates where I couldn't present you the
lecture, so it was shortened a bit.
So energy is not included this year.
But I wanted to definitely briefly show you a summary of this course.
So very brief summary, introduction we had there.
We had internet history and technology.
We looked at searching for information.
Important part to know actually how we can get information from the
electronic information that is stored on so many computers.
And nevertheless we have very short response times for queries on that
information.
We know how this is done by using indexes, suffix trees, appropriate
search engine technology.
And then we had cryptographic algorithms, showed you quite a few
things there.
And today we looked at electronic payment systems.
And internet of energy was not covered this term.
It is in the course smart energy distribution, which is not offered
anymore.
But all the recorded lectures are there, you can look at that.
And you can also still register for exams if you would like to take an
exam in those courses.
Now, at AIFB there are quite a few other courses available.
But AI courses are no longer available.
Organic computing, if it's an algorithm, smart energy distribution.
Currently it is planned that I retire this fall.
Maybe that I prolong that for another year.
But since the plan was that I retire end of September, it was adequate
to say that I don't teach this summer term.
Even if I prolong for another year, I will not teach the courses that
can be registered for.
I will concentrate on research and forwarding.
I would like to be sure that I can hand over my research group into
the hands of my successor.
My successor will be a professor for applied informatics for energy
systems.
And the selection process is just on its way.
But only in this summer or in the fall, the decisions will be taken on
that.
So, what else can you do?
You can take courses with my assistant, Padyum Shukla, on
computational economics, nature-inspired optimization.
You can go to seminars that we have on different topics.
You can write your thesis.
I will still supervise theses.
My assistants will do that.
And you can go to my colleagues, to Andreas Oberweis for information
systems, to Jörg Surer-Vetter.
Rudi Studer is retiring end of this term.
So, semantic web.
Applied cognitive system, autonomous driving is a topic of Marius
Zöllner, who is new at the AIFB.
And then there is another new professor, Zach.
He is working on information system engineering with the
Fachinformationszentrum, a repository for information on scientific
literature.
There is another chair, which is just being filled.
Applied informatics for critical infrastructures will be there,
hopefully in the summer term.
And there is another chair, which is just being selected.
Applied informatics in security.
And so you see a lot of information about what you can do in the
future.
But I will only be there partially, and not that much longer.
If you would like to do something, you are welcome to come to the
research center for information technology, Forschungszentrum
Informatik, get a job as a research assistant, or for writing your
thesis.
Now, I also wanted, since this is really my last lecture in front of
students, except for things I do at the Hector School, I wanted to
show you, or to make some...
Oh, I forgot to do something.
I wanted to give you some information, like this, these red
annotations should be taken out, actually.
I didn't want those.
Okay, doesn't matter.
I wanted to tell you a little bit how, if you have five minutes more
time, I can briefly tell you something about how actually a person
like me comes into such a position, and what happened to me during my
life.
Not very long.
Just what did I do?
How did I get at Karlsruhe?
So, I studied mathematics and informatics.
University in the north of Germany at Kiel.
Learned programming when I was 60, coding on punched paper tape.
Correcting programs by cutting out certain pieces of that, gluing in
another piece, and then you had corrected the program on punched paper
tape.
Very strange way of programming.
Now we have smartphones.
I did foreign studies in Canada, at Waterloo.
72, 73.
Very interesting for me.
I went to all the seminar talks that they had there, with foreign
scientists from all over North America.
And so I got information on all the interesting points in research in
computer science.
Very interesting.
Completely different from what I had heard at that time at Kiel.
Wrote my thesis on compiler correctness.
And then became a researcher at the University of Kiel.
Wrote my dissertation on algebraic semantics of reducible flow graphs.
Algebraic semantics.
Very formal stuff on trying to understand how we can actually build
correct compilers.
But I also had more interests, which were actually initiated by Ian
Monroe.
He was a teacher of me at Waterloo.
He had just got his PhD under the direction of Stephen Cook, who was
the father of NP completeness and things like that.
And so he actually did something to get me interested in algorithms.
And so I also was a visiting assistant professor at Queen's University
in Canada for one year.
And then we had research projects on algorithms for VLSI.
How I can actually design algorithms such that they can be implemented
in hardware.
Sorting algorithms, computer arithmetic and things like that.
I wrote my habilitation thesis on that.
And had a few temporary positions at different places in Germany.
And in Denmark.
And then I got called here by the University of Karlsruhe at that
time.
And started with parallel algorithms.
We designed systolic algorithms.
Nice ideas about highly parallel systems implemented in hardware.
We designed dynamically reconfigurable architectures.
And designed massively parallel variants of evolutionary algorithms.
Studied how they are influenced by the different parameters they have.
Dived into evolutionary algorithms and collinear optimization.
Particle swarms, multi-criteria optimization.
So methods are one of my key competences.
And then we looked into new media for teaching.
Nice programs.
We had virtual university concepts.
And we designed certain things.
We designed this NuKit tool, which we know now as an app for feedback
in courses.
And then we started to look at self-organizing systems.
I designed something which is organic computing.
We had a priority research program of the German Research Foundation.
And actually we designed generic system architectures and methods
based on traffic problems.
And transferred that into the energy system.
And finally we established here something which we now call energy
informatics.
And you see this is quite a journey through different topics.
And what you can see there is that it's important to be open for new
topics.
Wherever you go, you have to see where there are chances, where there
are interesting new ideas, opportunities to take and exploit them.
You should extend your own horizon.
Not just look very narrow at the current topic you are doing, but go
to talks, go to possibilities to learn something about alternative
ideas.
And then combine that into innovative new products.
When I was teaching, which I always did, I liked teaching, as you may
have noticed.
I would always like to get you interested in informatics and the
potentials of digitalization, use of information processing for all
kinds of applications.
To provide you with knowledge about fundamental principles and current
developments.
And I also emphasize always the responsibility of scientists and
engineers.
What you do should be something that should be beneficial for humans.
Otherwise, you should not do it.
Okay, so this is just something which you can also do many things in
this area.
There are many innovations and challenges and take your chances and be
responsible.
And if you are on the short term interested in doing something with my
group, come to the Research Center for Informatics for Information
Technology.
There are lots of opportunities.
We are still working on quite a few projects.
So you are welcome to work as research assistant or write your thesis
in my group.
Okay, thank you very much for your attention.
It was always a pleasure for me to teach for you.
And so, that's it.