GnuPG usage for automatic remote decryption

[Mike Inman]

Peter,

Thanks for engaging, and walls of words with way too long sentences are all
too easy to create - I'm also bad at occasionally using the wrong word
(public vs private, for instance) which can render the whole wall confused.

So, my main challenge is that I have to "code and release" this system to a
bunch of users who aren't going to be lifting a finger for security, but
want security anyway.  The basic topology is: many machines sold to various
customers around the world, with occasional data exchanged between machines
and occasional software updates sent out.  (Occasional meaning: 0 or more.)

In the (less important) description of my symmetric "obscurity" code,
background may help.  These are files generated by machines in the field,
for consumption by other machines in the field with no opportunity for key
exchange.  The reason I call it obscurity is because, eventually someone
may discover the algorithm and key - at which point the files can be
decrypted, modified, re-encrypted, etc.  There's nothing of inherent value
in these files, just option settings which anyone with physical access can
change anyway - but, we want reasonable assurance that "hackers" won't be
toying with the machines by playing with these files.

To achieve this "obscurity/security" machine to machine, I have embedded a
key in the executable code (I know, I know, but is there a better way that
does not rely on user actions?)  The "salt" in the algorithm is a block of
random data that becomes the first encrypted block.  The settings data is
then encrypted, and the hash of the salt+settings data is encrypted,
hopefully achieving the goals of:

a) settings are not stored in plaintext to prevent "easy hacking"

b) identical settings files will appear different when encrypted due to the
salt, even though the key and iv do not change, making one route to
discovery of the key a little harder, and

c) if anything is changed without knowledge of the key, iv and algorithm,
the hash of the decrypted settings will not match the hash traveling with
the encrypted file, preventing randomly tampered files from being accepted
as valid.

Since these machines are "released to the wild" and must occasionally
communicate with each other this way, with essentially no guarantee of
opportunity for updates after release, I don't see a more secure
alternative?


The more important function is distribution of updates, and this is the one
that I want to employ public/private key encryption since the update files
are generated in a controlled location where we have the opportunity to at
least attempt to keep the private key confidential.  TLS would be nice, but
our update files may also arrive via USB stick, aka sneakernet...  All the
other limitations still apply - machines are sent into the wild and may not
have the opportunity for updates for years, if ever, but when we do send an
update we want the machine to be as certain as possible that it is an
intact authorized update.  Additionally, it is desired (but not critical)
for the contents of the update to be opaque to anyone who may examine the
file.

Thanks for the refresher on practical usage of RSA - my last "under the
hood" work with it was in the 1980s... Would this example be a correct
usage?

1 - We will use an RSA keypair with modulus n, public exponent e and
private exponent d, public exponent pre-programmed on the machines when
manufactured, private exponent held at the company.

2 - The message we want to send securely is: "Software updater from 1.0 to
1.1" compute a secure hash SH of the message say using SHA-3-512

3 - Compute SHe = sk^d mod n

4 - Obscure the composite message SHe+"Software updater from 1.0 to 1.1"
using a pre-shared symmetric key and algorithm (perhaps as described above)

5 - Recipient machine de-obscures the composite message using the
pre-shared symmetric key

6 - Recipient machine decrypts SH = SHe^e mod n and then can be certain
that the message is valid because only the factory knows d

Unfortunately, my hands are somewhat tied with respect to key lifecycle.  I
might be able to update some keys on some machines, but there is always the
(high likelihood) that a machine with just the original key will be out
there needing an update.  I'm starting to see the attraction of gpgme for
managing a list of keys, and possibly invalidating older keys with new
updates, but does it provide a mechanism for multiple authentications on a
single message?  ( Like: SHe1+SHe2...+SHeN+"Authenticated message" ? )

Thanks,

Mike


On Wed, Apr 11, 2018 at 10:29 AM, Peter Lebbing <peter at digitalbrains.com>
wrote:

> On 11/04/18 14:51, Mike Inman wrote:
> > Encrypt the message with a symmetric algorithm, adding salt and a
> > hash/checksum to ensure validity.
>
> I'm not sure what you're salting exactly, but anyway, this is not the focal
> point of my reply. By the way, there are many ways to do what you describe
> in
> such a way that the hash is utterly pointless and not authentication. For a
> sweet example, check the use of CRC inside a stream cipher in WEP, the
> original
> encryption layer of wireless LANs :-). Stream cipher + CRC = major D'oh!
>
> > When I studied cryptography at Uni in the 1980s, they taught that
> > private/public key encryption was a more or less interchangeable affair -
> > the only difference between a private key and a public key is the manner
> in
> > which they are handled.
>
> This is only true for some algorithms and not for others, and even then
> only to
> some extent.
>
> For example, with RSA, encryption is: encrypt message with random key,
> RSA-encrypt this random key to the private key of the intended recipient.
>
> RSA signatures is the opposite, where a hash matching the signed data is
> RSA-"encrypted" to the public key. Only the private key can "encrypt" to
> the
> public key, so when anybody uses the public key to "decrypt" it, they can
> verify
> the hash matches and was produced by the holder of the private key.
>
> So for encryption, you choose the number and send it to the private key.
>
> In signing, you obtain the number by hashing and send it to the public key.
>
> They are mathematically equivalent. But note that the public and private
> key are
> not interchangeable. The public exponent usually has a very low Hamming
> weight
> while the private exponent is derived after fixing the public exponent.
> Simply
> exchanging public and private variables would not give an equivalent
> keypair,
> although mathematically they'd still work.
>
> > As such, I am a little disappointed in the GnuPGP
> > implementation that doesn't allow encryption with the private key to
> serve
> > as authentication and obscurity of the message - our
> > *** not private, but public *** key will be
> > obscured, but obviously not secured since attackers may have control of
> the
> > standard computer system it is contained in.
>
> Obscurity can be obtained by many low-complexity methods and is not a goal
> of
> OpenPGP. There is no O in PGP :-). (Oh, and the GnuPG implementation
> wouldn't
> usually add such a major deviation from the OpenPGP standard.)
>
> And how do you see this as authentication? The way you describe it, I'm
> thinking
> you simply reverse the roles of the public and private key, and you are
> thus
> encrypting the session key to the public key with your private key instead
> of
> the other way around. What does this achieve? As you'd then be sharing the
> symmetric encryption key with the world, anybody could re-encrypt their
> malicious data to that symmetric key, tag the so-called "encrypted"
> asymmetric
> algorithm output that only the private key can produce on and presto,
> "authenticated" data. If this is what you meant, well, I've just explained
> it's
> not authentication. If this is not what you meant, please elaborate.
>
> Okay, that was a wall of words with way too long sentences. So let me
> combine it
> with an example.
>
> 1 - We will use an RSA keypair with modulus n, public exponent e and
> private
> exponent d
>
> 2 - Choose symmetric key: sk = 0x2dfe0af9eeb3352c390791f4710a63da
>
> 3 - Encrypt "Transfer $ 1000 to Mike" using AES and the symmetric key sk
> from 2.
> Let's call this result "BONAFIDEDATA"
>
> 4 - Compute s = sk^d mod n
> This is "encrypting" the symmetric key sk to the public key. It is equal
> to what
> PKCS#1 would consider the signature primitive RSASP1, mathematically
> equivalent
> to the decryption primitive RSADP.
>
> 5 - Send s + "BONAFIDEDATA" to recipient
>
> 6 - Recipient computes sk = s^e mod n
> This is "decrypting" the symmetric key sk using the public key. It is
> equal to
> what PKCS#1 would consider the verification primitive RSAVP1,
> mathematically
> equivalent to the encryption primitive RSAEP.
>
> 7 - Recipient decrypts "BONAFIDEDATA" using the correct sk, yielding
> "Transfer $
> 1000 to Mike".
>
> 8 - Mike has spending money.
>
> Now I come along.
>
> 1 - Intercept or observe on the network s + "BONAFIDEDATA". Preventing
> reception
> is optional.
>
> 2 - I compute sk = s^e mod n
> This is public data.
>
> 3 - Encrypt "Transfer $ 10,000 to Peter" using AES and sk, which we
> correctly
> determined to be 0x2dfe0af9eeb3352c390791f4710a63da. Let's call the result
> "FAKEDDATA"
>
> 4 - Send s + "FAKEDDATA" to recipient
>
> 5 - Recipient computes sk = s^e mod n
> This is "decrypting" the symmetric key sk using the public key. It is
> equal to
> what PKCS#1 would consider the verification primitive RSAVP1,
> mathematically
> equivalent to the encryption primitive RSAEP.
>
> 6 - Recipient decrypts "FAKEDDATA" using the correct sk, yielding "Transfer
> $ 10,000 to Peter".
>
> 7 - Peter has spending money, and then some.
>
> > Unless I'm missing something?
>
> If you were to use OpenPGP encryption instead of a shared symmetric key,
> key
> management and access revocation becomes much simpler. Additionally, you'd
> be
> encrypting much less data with the same symmetric key. So there are some
> more
> gotcha's with a static symmetric key: don't choose a symmetric algorithm
> with a
> 64-bit block size, etcetera. That's the thing about inventing your own
> crypto,
> even at such a high level. It seems much simpler to me to use a private
> key that
> is stored in plaintext on your recipient machine. Or TLS with the same,
> which by
> the way is an extremely common setup, much more so than a passphrase-less
> OpenPGP private key, even though they are the same principle.
>
> HTH,
>
> Peter.
>
> --
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180411/829f55b8/attachment.html>