Public key authentication of all Internet traffic

TidBITS Talk
#1

Thanks!!! Love to hear about identity validation fighting malware of all kinds.

I’m not sure if it would actually be possible, but for many years I’ve been trying to promote a potential theory (below) to enhance and validate web traffic.

CONCEPT: If all IP traffic started with a PKE handshake, so that every web transaction was validated as to authenticity on both ends, most fraud would become much more difficult.

DETAIL: In case you are not familiar with this, this is how I think it would work. Every net connected device has a MAC address. That or a similar unique token would be associated with an embedded hardware (secret) key for encryption-decryption. This would be paired with a public encryption-decryption key for that device. All network traffic would be allowed iff (if and only if) the sending and receiving network devices could validate their partner devices identity.

So a pc requesting an email transaction would start with its own secret key and encrypt the network transaction header with it and with the public key of the device to which it wishes to communicate.

The receiving device would use its secret key and the senders public key to decrypt and thus validate the source device authenticity. A security checksum of the message would be included in the encrypted header so the message could be proved to be original an un-tampered.

I suggested this scheme 30 years ago to the network guru at the University of Rochester. He didn’t argue it was not feasible, but only that he did not believe it would be reasonably feasible to do it AND to get buy in from enough institutions to create the necessary gravity to gain the wide acceptance required for universal adoption.

You may see a fatal flaw, in which case let me know. If not, please suggest to whom I can present it with the hope that with creation, testing, and adoption, we can make the internet a safer place for all.

Many thanks for your time!
John “Ty” Dibble

Caller ID Authentication May Tame the Scourge of Spam Calls
#2

That’s an interesting idea. Two questions spring to mind (though I think you have a much better understanding of the technical aspects of this, so I’ve possibly just misunderstood):

  1. Where would all the public keys be published and how will they be verified?

  2. Related to the first point, MAC addresses can be spoofed (the iPhone now has this as a built-in privacy feature), so couldn’t a spammer spoof a MAC and publish a public key to go with it?

#3

From the Wikipedia on the INTERNET:
The Internet has no single centralized governance in either technological implementation or policies for access and usage; each constituent network sets its own policies. The overreaching definitions of the two principal name spacesin the Internet, the Internet Protocol address (IP address) space and the Domain Name System (DNS), are directed by a maintainer organization, the Internet Corporation for Assigned Names and Numbers(ICANN). The technical underpinning and standardization of the core protocols is an activity of the Internet Engineering Task Force(IETF), a non-profit organization of loosely affiliated international participants that anyone may associate with by contributing technical expertise.

I’ve been away from this technology to long to be trusted to be correct, but I believe the system of access from one device to connect to another device is handled by a distributed hierarchical database of domain name address pairs. The originator device asks its local directory for the network path map to its requested destination device. The local directory checks its own database and if it finds the path mapping and if it has been “recently validated”, it provides it to the requesting device. If it does not have the requested data (or it is potentially “out of date”), it passes the request on to its hierarchical parent database (and so on) until the network path map is identified. The path mapping is returned to the requesting device which uses it to send its data packets into the internet with the path mapping encoded to allow it to arrive at its desired destination.

I’m not certain, but I believe this underlying layer of network protocols could support the new top layer of encrypted data streams. While my original proposal was to use this scheme to “protect” email data, it should be extensible to support other internet data streams, which should provide improved protection from much of the current spoofing and associated hacking/malware.

1 Like
#4

What you’ve described is a lot of processing for a single packet of data on the internet. There are still a lot of devices with slow processors that connect to the internet, With average packets of about 500 to 1000 bytes, that’s a lot of encryption and decryption being done using complex asymmetric encryption (which is much slower than symmetric encryption with a single key, like AES). And for time-sensitive data streams (voice, video streams, etc.), I just don’t think performance would be near enough to guarantee useful connections.

While TLS/SSL uses asymmetric encryption to establish a connection, it uses this handshake to establish a symmetric encryption key to be used for the connection from that point on, basically for that reason - it’s much less processor intensive.

As for DNS, it’s used to establish the address of named servers, generally not endpoints such as your home router or your mobile carrier’s router. Servers don’t do name lookups of devices connecting to them, and expanding DNS with holding public keys of every endpoint on the internet is extremely complicated. How fast will it be to get your device’s public key published when it first connects to the internet? How fast does this public key record get pushed to other DNS servers? Does your NAT router now need to be a DNS server to hold the keys of all devices behind the router?

What about the iPhone’s private address option, where by default the iPhone creates a different MAC address for each WiFi network? The iPhone would have to generate a different public/private key pair and manage those for each WiFi network (not a terrible problem, just one more complicated thing.) As this shows, MAC address spoofing is possible (and people have been doing it for a long time.)

Also, all the work that’s being done to help stop tracking us by ad networks would be out the window when they will simply be able to track the MAC address (or even just the private key) of our connections across networks. A project like TOR might be useless, as all of that processing done to anonymize user traffic would be pointless.

And the caller id spoofing problem would remain, as it’s really not a problem of internet protocol.

1 Like
#5

Thank you so much for such an expansive and educational response. It will take some time to understand it all. I really appreciate it.
Ty

#6

My original idea was not impossible and has been implemented for email, to my happy surprise. Wiki info below:

Now that we know this is really possible for the limited case of email, does anyone see a path to expanding the principle to other web traffic?

Thanks for your thoughts/replies!

#7

It’s already done. Part of the HTTPS protocol. A site’s certificate contains the domain(s) for which it is valid. If the certificate’s domain doesn’t match the site, then browsers issue a warning alerting you that it should not be trusted.

As long as the certificates are issued by well known and trusted organizations, the system works great.

#8

Thanks!!! Now I’m much happier!

image.png