Verifying standalone client

kidcrazy · May 20, 2017, 9:34pm

Hi there,

I’m not sure if I’m just too blind to see, but:
Is there any tutorial about how to verify integrity + publishing identity of the standalone client?

Until nis-ncc-0.6.82, I did this via the pgp signature file of gimre (fingerprint: 5621 B060 D4A2 15CE E807 2B14 63B5 4713 A464 94A9) that was delivered with each release. Now there’s a reference to a transaction on the blockchain.
Also, the standalone files are hosted on http://bob.nem.ninja/ via http, i.e. without any transport encryption or protection from manipulation.

Now, how do I verify the binaries before using them? Especially if I have no or just a very old NIS instance running?

Thanks in advance,
Kc

suky321 · May 21, 2017, 5:37am

There is a .sig file that you can check to verify the pgp signature. There are freely available software on the Internet.

kidcrazy · May 21, 2017, 8:08am

Hi suky,

the .sig file does not contain a pgp signature anymore.

E.g. nis-ncc-0.6.87.tgz.sig contains the lines

txId: f5ae6efac6b3f2dc109aa0a9e8fd4925a2308291b0e9a7976358c3913dc9e9c5
block: 1072404

How am I supposed to get a pgp signature from that?

Regards,
Kc

gevs · May 21, 2017, 11:02am

@rb2 I have seen you discuss this I think for your docker container, maybe you know what is needed here?

@kidcrazy maybe having a look at https://github.com/rb2nem/nem-docker will help because I think thats where rb2 encountered the same issue.

rb2 · May 21, 2017, 11:26am

Here is how it is done in the docker file:

# extract sha published:
sha=$(curl -s http://bigalice3.nem.ninja:7890/transaction/get?hash=$(curl -s  http://bob.nem.ninja/nis-ncc-0.6.87.tgz.sig | grep txId | sed -e 's/txId: //') | jq -r '.transaction.message.payload[10:]')
# verify the sha. 
    echo "$sha nis-ncc-0.6.87.tgz"  > /tmp/sum &&  sha256sum -c /tmp/sum

Let me know if you need more details

Here’s the link to the code:

github.com

rb2nem/nem-docker/blob/master/Dockerfile#L15


RUN dnf -y upgrade nss


# NEM software
RUN curl -L http://bob.nem.ninja/nis-0.6.95.tgz > nis-0.6.95.tgz


#RUN curl http://bob.nem.ninja/nis-0.6.95.tgz.sig > nis-0.6.95.tgz.sig
#RUN gpg --keyserver keys.gnupg.net --recv-key A46494A9
#RUN gpg --verify nis-0.6.95.tgz.sig nis-0.6.95.tgz


# New signature scheme, not always published
RUN sha=$(curl -L -s http://bigalice3.nem.ninja:7890/transaction/get?hash=$(curl -L -s  http://bob.nem.ninja/nis-0.6.95.tgz.sig | grep txId | sed -e 's/txId: //') | jq -r '.transaction.message.payload[10:74]') && \
echo "$sha nis-0.6.95.tgz"  > /tmp/sum && \
sha256sum -c /tmp/sum


RUN tar zxf nis-0.6.95.tgz


RUN useradd --uid 1000 nem
RUN mkdir -p /home/nem/nem/ncc/
RUN mkdir -p /home/nem/nem/nis/
RUN chown nem /home/nem/nem -R

kidcrazy · May 21, 2017, 2:25pm

@gevs @rb2 thanks for elaborating

Anyhow, I see some issues with this approach. Please correct me if I’m wrong.

1.) The package is checked against an arbitrary transaction in the blockchain. If an attacker is able to replace both the package (.tgz) and the signature file (.tgz.sig), and he includes an appropriate transaction in the blockchain, then the check would also succeed. I.e. the binaries are checked for integrity, but the are not checked for the issuers identity.
This could e.g. be exploited if someone claims to operate a mirror for the binaries and replaces the files by malicious ones at some arbitrary point in time.

2.) Both .tgz and .tgz are published via http, which makes it easy for a man-in-the middle to replace the content of both files.

3.) The sha256 is determined by querying another nem node (igalice3.nem.ninja in this case) for the transaction content via http. The user is forced to trust the node and anyone between the two (potential man-in-the-middle) to not tamper with the content.

So, as I see it atm, the integrity + identity check via PGP signature has been replaced by an integrity check only.
I would like to see the PGP signature file be added for download again.

Regards,
Kc

P.S.: Maybe it’s also possible to include an identity check against the issuer of the transaction and query the users own xem node instead a remote one.

rb2 · May 21, 2017, 6:25pm

I agree with you @kidcrazy. It is an issue I have raised in the past too, and the solution for now is to check that the account issuing the transaction is one of the well known NEM accounts. I think it should be fixable by using a well identified account, or maybe even better by combining it with the NEM namespace feature. But I’m not yet well versed with the namespaces, maybe @jabo38 can ellaborate if he reads this?

kidcrazy · May 22, 2017, 10:26am

Ok, so now I got a bit further:

node=bigalice3.nem.ninja:7890
#node=localhost:7890
file=nis-ncc-0.6.87.tgz

validSigners=(
“826cedee421ff66e708858c17815fcd831a4bb68e3d8956299334e9e24380ba8”
#“another valid signers address”
)

function contains() {
local n=$#
local value=${!n}
for ((i=1;i < $#;i++)) {
if [ “${!i}” == “${value}” ]; then
echo "y"
return 0
fi
}
echo "n"
return 1
}

txid=$(cat $file.sig | grep txId | sed -e ‘s/txId: //’)
transaction=$(curl -s “http://$node/transaction/get?hash=$txid”)
sha=$(echo $transaction | jq -r ‘.transaction.message.payload[10:]’)
signer=$(echo $transaction | jq -r ‘.transaction.signer’)
rm /tmp/sum
echo “$sha $file” > /tmp/sum
intergrity="FAIL"
integrity=$(sha256sum -c /tmp/sum)

if [ “${integrity:(-2)}” != “OK” ]
then
echo "bad checksum"
elif [ $(contains “${validSigners[@]}” “$signer”) != “y” ]
then
echo "unknown signer"
else
echo "everything ok :)"
fi

This script checks integrity + identiy of the downloaded package + .sig file.
However, atm it only works with the node bigalice3.nem.ninja. It seems my own node can’t find the transaction hash.

If i call

echo $(curl -s “http://localhost:7890/transaction/get?hash=f5ae6efac6b3f2dc109aa0a9e8fd4925a2308291b0e9a7976358c3913dc9e9c5”)

I just get

{“timeStamp”:67861181,“error”:“Bad Request”,“message”:“Hash was not found in cache”,“status”:400}

Anyone knows what to do here?

Regards,
Kc

gevs · May 22, 2017, 10:58pm

yes if you want your node to cache transactions, you must set that in the configuration file nis/config.properties (not sure if you can overwrite with config-user file)

gevs · May 22, 2017, 11:01pm

I’m not an expert on Apostille but what you guys are trying to do is exactly what Apostille does. If someone, with a reputable account would create an Apostille uploading the NCC binaries etc., it would be verifiable on the blockchain with Apostille Audits

For Nanowallet this is already the case, the downloaded NanoWallet archive is an Apostille Archive which can be audited with the NanoWallet itself

kidcrazy · May 23, 2017, 4:59am

@gevs yes, I already stumbled across that feature. Unfortunately, this option seems to be already activated by default. At least it is already included in my nis/config.properties file:

# Optional features supported by the local node (pipe-separated).
# TRANSACTION_HASH_LOOKUP: transactions can be retrieved by supplying the transaction hash.
# HISTORICAL_ACCOUNT_DATA: historical account data can be retrieved.
nis.optionalFeatures = TRANSACTION_HASH_LOOKUP

But it doesn’t seem to work for me.

As for Apostille: Is there a way to access that functionality via nis/ncc? Because as long as it is not, I don’t see why the PGP signature has been removed. Also, I still see a big issue for people downloading the client for the first time, as there is no https encryption used for the download.

I really think those two (PGP signature + https) should be added for the official download location (where you get from www.nem.io website). After all, this is the main software to keep your funds safe. It should not just lay there unprotected to wait for some malicious hacker to infiltrate the next wave of newcommers. Anyhow, I just don’t know who to address with those concerns.

gevs · May 23, 2017, 11:05am

@BloodyRookie i think having a ssl certificate for bob.nem.ninja:80 would be nice.

@kidcrazy i think it was planned that next releases would be “apostilled” but i am really not sure here.