R devel - Oct 2015 - Package integrity check via SHA256 or OpenPGP possible?

Dear list,

I'm using R in a corporate environment and was interested how R checks
integrity of packages during an installation.
I saw (and verified my suspicion in the code[1]) that the verification purely
relies on MD5.
>From an IT security perspective, this can be improved.
My question is: Is is possible to force R to verify integrity via SHA256 or even
OpenPGP signatures?
If not are there any plans to support better hashes than MD5?
As the source code looks, an extension to support other (optional) hash values
would be quite easy.

Thanks in advance!

Kind regards,
Philip

[1] see from line 594 on in src/library/tools/R/install.R in R-latest.tar.gz






---
Alle Postf?cher an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen!
http://email.freenet.de/basic/Informationen

On Thu, Oct 15, 2015 at 9:11 AM, Philip Gilli?en <guerda at freenet.de>
wrote:
> I'm using R in a corporate environment...
That's irrelevant.
> is possible to force R to verify integrity via SHA256 or even OpenPGP
signatures? If not are there any plans to support better hashes than MD5? As the
source code looks, an extension to support other (optional) hash values would be
quite easy.
A hash is not the same thing as a signature. If you need an
introduction to these topics I recommend www.crypto101.io.

Adding sha256 support would indeed be easy but we wouldn't gain much.
Coincidental md5 collisions are very unlikely. If you are considering
deliberate attacks on the network, a hash function is not going to
help as the attacker can just recompute the hash along with the
tampered package.

Also note that if you are using an https mirror, the connection
between you and the mirror should be secure. But of course it is still
possible that a mirror server itself gets hacked.

Now, signing packages with a private key would be useful against such
attacks, but require quite a bit of work. If we would follow the
Debian model, it would require that:

 - Each of the PACKAGES files in the repository gains a secure hash
(e.g. sha256) for each file in the directory.
 - A "Release" file [1] is added to the repository that includes a
secure hash of each of the PACKAGES files.
 - A "Release.gpg" file [2] or equivalent is added which contains a
signature of the "Release" file.
 - Each time "PACKAGES" and hence "Release" files are
updated, the
repository maintainers need to update "Release.gpg" by signing
"Release" with their private key.
 - R installations would have to ship with the corresponding public
key in order to verify the signature in Release.gpg before installing
packages.
 - All of this would have to be implemented using a crypto library
capable of public key signatures.
 - A policy is designed for rotating keys when they expire, or between
R releases, or when one gets compromised, etc.

I have actually been looking into this over the past few months. On
Linux it would be doable with gpg, but unfortunately gpg does not work
very well on OSX and Windows, which make it impractical for R.

There are a few alternatives that are more portable. The PKI package
uses openssl to do RSA signatures, which could work. The new 'sodium'
package is probably the most advanced thing currently available. It
uses the ed25519 public-key signature system with a very simple API.
See the manual page for the 'sig_sign' and 'sig_verify'
functions.

Either way, all this would require a substantial amount of work and
additional ongoing maintenance in both R and CRAN, which is unlikely
to happen given the limited resources.


[1] http://http.us.debian.org/debian/dists/jessie/Release
[2] http://http.us.debian.org/debian/dists/jessie/Release.gpg

> On 15 Oct 2015, at 08:11, Philip Gilli?en <guerda at freenet.de>
wrote:
> 
> Dear list,
> 
> I'm using R in a corporate environment and was interested how R checks
integrity of packages during an installation.
> I saw (and verified my suspicion in the code[1]) that the verification
purely relies on MD5.
>> From an IT security perspective, this can be improved.
Maybe, but 'IT security' was not the point.  MD5 sums were added first
as a way to check for corrupted downloads/unpacking (which used to be common on
Windows), and second to reinforce the version number of a package as sometimes
the source package is altered without changing the version, and less rarely
binary packages are re-built.

> 
> My question is: Is is possible to force R to verify integrity via SHA256 or
even OpenPGP signatures?
> If not are there any plans to support better hashes than MD5?
> As the source code looks, an extension to support other (optional) hash
values would be quite easy.
> 
> Thanks in advance!
> 
> Kind regards,
> Philip
> 
> [1] see from line 594 on in src/library/tools/R/install.R in
R-latest.tar.gz
> 
> 
> 
> 
> 
> 
> ---
> Alle Postf?cher an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen!
http://email.freenet.de/basic/Informationen
> 
> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

FWIW PKI supports signing and verification of tar balls based on X.509
(PKI.sign.tar/PKI.verify.tar) - the aim was to specifically support signing of
packages so we could have infrastructure akin to the Apple developer code
signing where the repository would be the CA (e.g., CRAN, RForge.net, etc.).
Obviously, it's just one approach, but at least it is already implemented.

This is getting OT as others have pointed out since the purpose of the hashes is
an integrity check, not security, but I absolutely agree that it would be nice
to have some kind of signing to validate the source of packages (=verifiable
authorship).

Cheers,
Simon

> On Oct 15, 2015, at 9:51 AM, Jeroen Ooms <jeroen.ooms at
stat.ucla.edu> wrote:
> 
> On Thu, Oct 15, 2015 at 9:11 AM, Philip Gilli?en <guerda at
freenet.de> wrote:
>> I'm using R in a corporate environment...
> 
> That's irrelevant.
> 
>> is possible to force R to verify integrity via SHA256 or even OpenPGP
signatures? If not are there any plans to support better hashes than MD5? As the
source code looks, an extension to support other (optional) hash values would be
quite easy.
> 
> A hash is not the same thing as a signature. If you need an
> introduction to these topics I recommend www.crypto101.io.
> 
> Adding sha256 support would indeed be easy but we wouldn't gain much.
> Coincidental md5 collisions are very unlikely. If you are considering
> deliberate attacks on the network, a hash function is not going to
> help as the attacker can just recompute the hash along with the
> tampered package.
> 
> Also note that if you are using an https mirror, the connection
> between you and the mirror should be secure. But of course it is still
> possible that a mirror server itself gets hacked.
> 
> Now, signing packages with a private key would be useful against such
> attacks, but require quite a bit of work. If we would follow the
> Debian model, it would require that:
> 
> - Each of the PACKAGES files in the repository gains a secure hash
> (e.g. sha256) for each file in the directory.
> - A "Release" file [1] is added to the repository that includes a
> secure hash of each of the PACKAGES files.
> - A "Release.gpg" file [2] or equivalent is added which contains
a
> signature of the "Release" file.
> - Each time "PACKAGES" and hence "Release" files are
updated, the
> repository maintainers need to update "Release.gpg" by signing
> "Release" with their private key.
> - R installations would have to ship with the corresponding public
> key in order to verify the signature in Release.gpg before installing
> packages.
> - All of this would have to be implemented using a crypto library
> capable of public key signatures.
> - A policy is designed for rotating keys when they expire, or between
> R releases, or when one gets compromised, etc.
> 
> I have actually been looking into this over the past few months. On
> Linux it would be doable with gpg, but unfortunately gpg does not work
> very well on OSX and Windows, which make it impractical for R.
> 
> There are a few alternatives that are more portable. The PKI package
> uses openssl to do RSA signatures, which could work. The new
'sodium'
> package is probably the most advanced thing currently available. It
> uses the ed25519 public-key signature system with a very simple API.
> See the manual page for the 'sig_sign' and 'sig_verify'
functions.
> 
> Either way, all this would require a substantial amount of work and
> additional ongoing maintenance in both R and CRAN, which is unlikely
> to happen given the limited resources.
> 
> 
> [1] http://http.us.debian.org/debian/dists/jessie/Release
> [2] http://http.us.debian.org/debian/dists/jessie/Release.gpg
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel