diff options
| -rw-r--r-- | archive/2022-03-14-notes-on-sigsum-and-rekor.md | 533 |
1 files changed, 533 insertions, 0 deletions
diff --git a/archive/2022-03-14-notes-on-sigsum-and-rekor.md b/archive/2022-03-14-notes-on-sigsum-and-rekor.md new file mode 100644 index 0000000..d19e696 --- /dev/null +++ b/archive/2022-03-14-notes-on-sigsum-and-rekor.md @@ -0,0 +1,533 @@ +# A frequently asked question +We are frequently asked how Sigsum compares to Sigstore. This document +highlights some technical similarities and differences as of March, 2022. + +Sigstore's sub-project Rekor and Sigsum are both transparency log designs that +aim to make a signer's key-usage transparent. By enabling end-users to verify +that signatures they trust are public, they are protected from accepting +malicious signatures that were created in secret (e.g., due to key compromise). + +The following transparency log concepts are explored side-by-side: + + - Purpose of logging + - What is logged + - Auditing + - Gossip + - Anti-poison + - Anti-spam + - Privacy + - API + - Promises of future logging (SCTs) + - Sharding + +There is also an Appendix at the end with relevant code snippets. + +## Purpose of logging + +**Sigsum** + +No signature that an end-user accepts as valid should go unnoticed by anyone who +inspects the log. + +Sigsum is designed to be secure even if an attacker controls: + + - The signer's infrastructure and signing key + - The log's infrastructure and signing key + - A threshold of independent witnesses that cosign the log + +The log operator is not trusted beyond being available at the time of logging. + +**Sigstore/Rekor** + +[Rekor's README][] says that the goal is to "[e]nable software maintainers and +build systems to record signed metadata to an immutable record", and that it +"fulfils the signature transparency role of sigstore's software signing +infrastructure". [No threat model][] is available at the time of writing. + +[Rekor's README]: https://github.com/sigstore/rekor/tree/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5#readme +[No threat model]: https://web.archive.org/web/20220312143825/https://docs.sigstore.dev/security/ + +## What is logged + +**Sigsum** + +A shard hint, a SHA256 checksum, an Ed25519 signature, and a SHA256-hashed +public key. The signed blob is based on the [SSH format][]. The logged +signatures are verifiable by anyone who knows the corresponding public keys. + +[SSH format]: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig + +**Sigstore/Rekor** + +Signed manifests called [pluggable types][]. The rekord type allows signatures +based on Signify, Minisign, SSH, and PGP, as well as PKIX/X.509. For example, +you could log a signature for a PGP email that was received in 2002. There are +several other pluggable types with more to come. Rekor is overall permissive. + +Some pluggable type signatures are not verifiable in isolation for a monitor +that observes the log because to verify a signature data is needed that is not +included in the log and might be known only to the creator of the signature, see +"Example 1: unverifiable signatures" in the Appendix at the end. This means +that it is impossible to distinguish between unverifiable log entries fabricated +by the log and log entries maliciously created with a signer's private key. + +[pluggable types]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/pkg/types/README.md + +## Auditing +How will end-users verify that public logging took place? + +**Sigsum** + +End-users receive inclusion proofs and cosigned tree heads that can be verified +offline in the same way that data and signatures are currently delivered (a +website, a git repository, etc). No other network communication is required. + +This means that a sigsum log does not have to be available to the end-user after +logging succeeded to verify that public logging took place. + +**Sigstore/Rekor** + +End-users [query the log][] to check that a signature is included. This means +the log needs to stay available to end-users at all times, also see "Privacy". + +Alternatively, an end-user may trust a signed promise (SCT) from Rekor to +include a signature in the future, see "Promises of future log inclusion". + +[query the log]: https://web.archive.org/web/20220312144545/https://www.sigstore.dev/how-it-works + +## Gossip +A mechanism that ensures everyone observes the same append-only log. A +transparency log without gossip requires trusting the log operator and the +integrity of the log's signing key. + +**Sigsum** + +Gossip is handled proactively using a simplified version of witness cosigning +([S&P 2016][]). It can be thought of as a policy-based consensus mechanism: +m-of-n witnesses audit the log's consistency from their respective vantage +points. The log distributes the witnesses' signatures, which end-users and +monitors make use of. This ensures that a malicious sigsum log operator is +unable to fool even an offline verifier. + +[S&P 2016]: https://arxiv.org/pdf/1503.08768.pdf + +**Sigstore/Rekor** + +Does not have gossip. Sigstore proposes to instead use multiple independent +[full-fledged logs][]. Logs have more freedom to fool a verifier than cosigning +witnesses and are harder and more expensive to run. + +Signers would have to take great care to submit the same entries to all the logs +and would have to monitor all of them. End-users would have to contact and/or +trust multiple logs when verifying. + +[full-fledged logs]: https://web.archive.org/web/20220312144801/http://web.archive.org/screenshot/https://docs.sigstore.dev/faq + +## Anti-poison +A transparency log design must take caution to not include large amounts of +arbitrary data, as someone could submit information that is illegal to possess +or distribute. Because the log operator cannot selectively erase information +from the log without invalidating it, the operator may be compelled to shut down +the log, or simply choose to not operate a log in the first place. + +**Sigsum** + +Include as little arbitrary information as possible. A log entry contains a +time value (a shard hint, in the interval `[shard_start, now()]`) of which the +least significant few bytes are arbitrary. The remaining content can only be +specified by brute forcing signatures or hashes so that parts of them contain +certain patterns. This quickly becomes expensive. + +**Sigstore/Rekor** + +The pluggable type system allows logging of a wide variety of information. The +rekord type for instance allows encoding an image, see "Example 2: logging JPG +images" in the Appendix at the end. Other current and future pluggable types +might permit similar things but we have not looked into that further. + +## Anti-spam +An approach to limit abusive logging requests that consume the log's capacity. + +**Sigsum** + +A logging request is only accepted if the involved public key is hashed into a +DNS TXT record. So, rate limits can be based on DNS names. This is similar to +the anti-spam mechanisms that CT relies on, where a certificate is not accepted +unless it chains up to a trusted CA. Let's Encrypt [rate-limits via DNS][]. + +[rate-limits via DNS]: https://web.archive.org/web/20220312145502/https://letsencrypt.org/docs/rate-limits/ + +**Sigstore/Rekor** + +Recently opened an issue about [needing rate-limits][]. It has since been added +to Sigstore's infrastructure setup based on IP addresses via Nginx. + +[needing rate-limits]: https://github.com/sigstore/rekor/issues/637 + +## Privacy + +**Sigsum** + +For end-users, nothing changes with regard to privacy compared to signature +verification that does not make use of a transparency log. + +A signer has to expose to the log operator a public key and a 32-byte preimage +([which should be a hash][]). + +The signer's hashed public key is exposed in DNS, see "Anti spam". Logs can be +be instructed to fetch such TXT resource records if they match `_sigsum_v0.*`. + +Log entries consisting of a shard hint, hashes and signatures become public, see +"What is logged". + +[which should be a hash]: https://git.sigsum.org/sigsum/tree/doc/design.md?id=741a65ab1894b35c9cc132d9b8401776c04fe1ce#n351 + +**Sigstore/Rekor** + +End-users that query the log for entries they are interested in expose this +information to the log. + +A signer's public key and data is exposed to the log operator. The data may be +a hash if [using X.509/PKIX][] signatures and the "hashed rekord type". + +Logs can be instructed to download arbitrary data from [specified URLs][]. + +The content of pluggable types become public, notably including public keys and +other data that may be encoded (which depends on the exact pluggable type). + +[using X.509/PKIX]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/types.md#hashed-rekord +[specified URLs]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/openapi.yaml#L143 + +## API + +**Sigsum** + +Simple ASCII parsers are used to add input and get output from the log. Binary +data is hex-encoded. Data that is signed and/or logged can be (de)serialized +using Tor's easy wire-format, [Trunnel][]. The overall take of the API is to +keep it as simple as possible, and to nudge towards correct usage by design. + +[Trunnel]: https://gitweb.torproject.org/trunnel.git/tree/doc/trunnel.md + +**Sigstore/Rekor** + +REST API with JSON, both for input and output as well as canonicalization of +data. Some parts of the API are easily misused due to returning redundant +and/or unauthenticated data. This happened [once][] and [twice][] already. + +Other types of mis-usage are likely to be expected. For example, the +availability of public keys makes it tempting to inappropriately use Rekor for +key discovery even though it is not designed to be a trustworthy source of keys. + +The implementation complexity of Rekor's API is also relatively large. Imports +contain much hidden complexity, in part due to pluggable types that involve PGP, +ASN.1, and such. This has already lead to issues like Rekor starting to return +[YAML instead of JSON][]; JSON marshalling of tree leaves [not being canonical +enough][]; the [need of another PGP library][]; etc. It will likely be hard to +understand, implement, and maintain Rekor compliant software in the long run. + +[once]: https://github.com/sigstore/rekor/issues/200 +[twice]: https://github.com/sigstore/rekor/pull/469 +[YAML instead of JSON]: https://github.com/sigstore/rekor/issues/593 +[not being canonical enough]: https://github.com/sigstore/rekor/pull/445 +[need of another PGP library]: https://github.com/sigstore/rekor/issues/286 + +## Promises of future log inclusion (SCTs) +A construct that enables low-latency logging. Certificate Transparency +introduced this to work with the existing TLS PKI during a gradual roll-out +scenario. Nine years later such roll-outs are still in the earlier stages. + +**Sigsum** + +Does not support SCTs. Unlike the TLS case there is no existing system to be +compatible with and use-cases that cannot tolerate a few minutes of logging +latency are out-of-scope. This is a trade-off that keeps the design simple. + +**Sigstore/Rekor** + +[Supports SCTs][]. If an entry (promised to be logged by an SCT) is not included +in the log in time the operator should not be trusted in the future. This +places high requirements on uptime and availability, and on not losing the log +request between the time of issuing an SCT and inclusion in the log. Rekor +avoids this by simply including the signature in the log [before issuing][] the +SCT. That however provides no latency reduction, making SCTs pointless. + +The mere existence of SCTs also encourages their use, making users who rely on +them not receive the full benefits of using a transparency log. We are not +aware of any clear plans specifying how Sigstore will solve SCT verification. +Without such plans, the log may deceive end-users by changing its history. + +[Supports SCTs]: https://twitter.com/lorenc_dan/status/1388109774579982340 +[before issuing]: https://github.com/sigstore/rekor/blob/a61d5f63843cbae4e5bf1f97d06628fa914a4435/openapi.yaml#L493 + +## Sharding +The practise of dividing a log into smaller independent partitions. One of +Certificate Transparency's successes is [temporal sharding][] based on expiry +date to allow log rotation (helpful to make log life cycles more manageable). + +[temporal sharding]: https://web.archive.org/web/20220312150931/https://googlechrome.github.io/CertificateTransparency/log_policy.html + +**Sigsum** + +Establishes shards based on shard hints in the interval `[shard_start, now()]`. +Shard hints are part of the signer's signing context and cannot be forged, +preventing past entries from being re-logged in a newer shard. A log can also +cease its operations safely due to Sigsum's take on offline auditing. This +gives a complete story for log life cycles without any expiration dates. + +**Sigstore/Rekor** + +Creates [virtual shards][], see also related [GitHub issues][]. The latest +virtual shard is active. All other virtual shards are kept around but in +read-only mode. If a virtual shard was to be deleted those entries can be +logged again. As old virtual shards have to be saved, this gives a complicated +log configuration but does not provide any of the benefits of sharding. + +[virtual shards]: https://docs.google.com/document/d/1QBTyK-wquplNdeUB5_aqztQHigJOepCvd-4FL4H-zl8/edit?resourcekey=0-grdVbSltkTvpNvhj03laCQ# +[GitHub issues]: https://github.com/sigstore/rekor/issues/353 + +# Appendix +## Example 1: Unverifiable signatures +The input to a signature verification is a public key, a message, and a +signature. Rekor incorrectly assumes that the signed message ("artifact") +is always a hash. + +First we demonstrate the issue using `signify`. + +**Step 1 - Generate a key-pair** + + $ signify-openbsd -G -c "demo" -p example.pub -s example.sec + passphrase: + confirm passphrase: + $ ls + example.pub example.sec + +**Step 2 - Create something to sign** + + $ echo 'print("hello")' > hello.py + $ sha256sum hello.py + b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180 hello.py + $ ls + example.pub example.sec hello.py + +**Step 3 - Sign** + + $ signify-openbsd -Ss example.sec -m hello.py + passphrase: + $ ls + example.pub example.sec hello.py hello.py.sig + +**Step 4 - Log** + +The below uses Rekor on commit 6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5. + + $ rekor-cli upload \ + --artifact hello.py\ + --signature hello.py.sig\ + --pki-format=minisign\ + --public-key=example.pub\ + --rekor_server http://localhost:3000 + Created entry at index 99, available at: http://localhost:3000/api/v1/log/entries/bf5f87c83bfffc3b0d3d0151a6cfef836594dcd90ac286541b25856b7d6fd6b1 + $ rekor-cli get --log-index 99 --rekor_server http://localhost:3000 + LogID: e0f8a8ff472431bda298489c292f33f5d30363949df58d2e35c5195f915c7069 + Index: 99 + IntegratedTime: 2022-03-12T11:59:28Z + UUID: bf5f87c83bfffc3b0d3d0151a6cfef836594dcd90ac286541b25856b7d6fd6b1 + Body: { + "RekordObj": { + "data": { + "hash": { + "algorithm": "sha256", + "value": "b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180" + } + }, + "signature": { + "content": "dW50cnVzdGVkIGNvbW1lbnQ6ClJXVE9PWDNrMjE0L3VDR0VuQWtHaC9wOGxCK2o4ZlU0bzN2aFpzc3dud2RFeDE2M2REUHpReE1BVXdUcUFjK1ovaGdycGdISU5VNHlFbnhPOXNwSnkydmZmcHdWSUJIV3lnWT0=", + "format": "minisign", + "publicKey": { + "content": "UldUT09YM2syMTQvdUg1RVhHbUFwdDZWSnhxVUlJZzIrWnMrajlFRDNTM1ZGOXBHSzZoWDRLSmM=" + } + } + } + } + +Let's understand the above in more detail. Our public key and signature is in +the above output, but without the untrusted comment which is irrelevant. + + cat example.pub + untrusted comment: demo public key + RWTOOX3k214/uH5EXGmApt6VJxqUIIg2+Zs+j9ED3S3VF9pGK6hX4KJc + $ echo UldUT09YM2syMTQvdUg1RVhHbUFwdDZWSnhxVUlJZzIrWnMrajlFRDNTM1ZGOXBHSzZoWDRLSmM= | base64 -d + RWTOOX3k214/uH5EXGmApt6VJxqUIIg2+Zs+j9ED3S3VF9pGK6hX4KJc + $ + $ cat hello.py.sig + untrusted comment: verify with example.pub + RWTOOX3k214/uCGEnAkGh/p8lB+j8fU4o3vhZsswnwdEx163dDPzQxMAUwTqAc+Z/hgrpgHINU4yEnxO9spJy2vffpwVIBHWygY= + $ echo "dW50cnVzdGVkIGNvbW1lbnQ6ClJXVE9PWDNrMjE0L3VDR0VuQWtHaC9wOGxCK2o4ZlU0bzN2aFpzc3dud2RFeDE2M2REUHpReE1BVXdUcUFjK1ovaGdycGdISU5VNHlFbnhPOXNwSnkydmZmcHdWSUJIV3lnWT0=" | base64 -d + untrusted comment: + RWTOOX3k214/uCGEnAkGh/p8lB+j8fU4o3vhZsswnwdEx163dDPzQxMAUwTqAc+Z/hgrpgHINU4yEnxO9spJy2vffpwVIBHWygY= + +Rekor also stored a SHA256 hash: + + "RekordObj": { + "data": { + "hash": { + "algorithm": "sha256", + "value": "b80792336156c7b0f7fe02eeef24610d2d52a10d1810397744471d1dc5738180" + } + }, + +You might recognize it from step 2. It is the output of `sha256sum hello.py`. +What is needed to do verification with the logged signature and public key is +the output of `cat hello.py`. This is because signify signs those exact bytes +without doing any hashing (unlike other schemes that actually do sign a hash). + +The impact is that you cannot know by observing the log if a real signature +operation happened (there is nothing to verify), or if the Rekor operator +fabricated an entry. The signature would be verifiable if the data can be +located. In the case of a malicious signature this might not be the case. + +**The same issue in other places** + +Minisign has the same issue, even with its pre-hashed mode because Minisign +[does not use SHA256][] which is what Rekor still stores. The exact same issue +is also there for SSH signatures. We did not dig into any other types. + +[does not use SHA256]: https://github.com/sigstore/rekor/blob/6ace9fe63b072a3a7e8b544fcbf393d2aafe9ae5/pkg/pki/minisign/minisign.go#L109 + +## Example 2: Logging JPG images +As shown above Rekor scrubs some information that was submitted for logging. +Most likely to not accept arbitrary bytes, such as signify's untrusted comments. +To protect Rekor against logging of illegal content, each pluggable type needs +to be considered in more detail. Below is an example that encodes a JPG image. + +**Step 1 - Create an image** + + $ convert -size 16x16 xc:red red.jpg + $ ls + red.jpg + +This also works with larger images, e.g., `-size 4096x4096`. + +**Step 2 - Encode image in an X.509 configuration** + + $ echo "[ req ]" > crt.cnf + $ echo "distinguished_name = dn" >> crt.cnf + $ echo "x509_extensions = extensions" >> crt.cnf + $ echo "prompt = no" >> crt.cnf + $ echo "" >> crt.cnf + $ echo "[ extensions ]" >> crt.cnf + $ echo "1.2.3.4 = ASN1:UTF8String:$(base64 -w0 red.jpg)" >> crt.cnf + $ echo "" >> crt.cnf + $ echo "[ dn ]" >> crt.cnf + $ echo "0.DC = com" >> crt.cnf + $ echo "1.DC = example" >> crt.cnf + $ echo "commonName = example.com" >> crt.cnf + $ ls + crt.cnf red.jpg + +Credit: [this post][] outlines how an X.509v3 extension can be prepared. + +[this post]: https://serverfault.com/questions/1005029/error-when-trying-to-add-custom-extensions-to-x509-certificates-using-openssl + +**Step 3 - Create X.509 certificate** + + $ openssl req -x509 -nodes\ + -newkey ec:<(openssl ecparam -name prime256v1)\ + -config crt.cnf\ + -keyout priv.pem\ + -out cert.pem + Generating an EC private key + writing new private key to 'priv.pem' + ----- + $ ls + cert.pem crt.cnf priv.pem red.jpg + +Note that we now have an X.509 certificate that encodes our image: + + $ openssl x509 -in cert.pem -text -noout + Certificate: + Data: + Version: 3 (0x2) + Serial Number: + 27:a5:0e:37:9c:3e:e1:0d:d7:a4:8f:10:ce:2d:09:35:40:9c:a8:1e + Signature Algorithm: ecdsa-with-SHA256 + Issuer: DC = com, DC = example, CN = example.com + Validity + Not Before: Mar 12 13:46:06 2022 GMT + Not After : Apr 11 13:46:06 2022 GMT + Subject: DC = com, DC = example, CN = example.com + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (256 bit) + pub: + 04:9d:2a:5d:4c:df:d4:fa:9a:76:32:59:96:3b:44: + 12:00:03:3c:c0:d9:42:58:c1:fb:2a:ed:fb:0d:95: + d0:ce:7d:62:e6:f8:ae:be:76:6b:3b:0c:44:aa:ca: + 43:57:cf:19:a3:c9:b1:cd:05:21:a2:b8:0c:50:13: + 0c:d9:9f:8f:ea + ASN1 OID: prime256v1 + NIST CURVE: P-256 + X509v3 extensions: + 1.2.3.4: + ..../9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAQABADAREAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAj/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFgEBAQEAAAAAAAAAAAAAAAAAAAcJ/8QAFBEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AnRDGqYAAD//Z + Signature Algorithm: ecdsa-with-SHA256 + 30:46:02:21:00:ee:ee:81:d6:1c:e8:a7:ca:dd:54:b5:82:fe: + 22:1d:94:1d:b1:31:91:d6:3e:68:99:f5:d5:da:c9:f4:bc:53: + 53:02:21:00:cd:08:98:c5:73:e8:a1:8f:8c:95:06:cc:5c:70: + 65:aa:dd:94:f0:38:59:ec:f7:c7:35:98:eb:75:5f:23:eb:c5 + +Compare the X.509v3 extensions to this: + + $ base64 red.jpg + /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAAQABADAREAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAj/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFgEBAQEAAAAAAAAAAAAAAAAAAAcJ/8QAFBEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AnRDGqYAAD//Z + +Now we need to get this X.509 certificate into Rekor. + +**Step 4 - Sign something** + + $ openssl dgst -sha256 -sign priv.pem -out red.jpg.sig red.jpg + $ ls + cert.pem crt.cnf priv.pem red.jpg red.jpg.sig + +**Step 5 - Log** + + $ rekor-cli upload \ + --artifact red.jpg\ + --signature red.jpg.sig\ + --pki-format=x509\ + --public-key=cert.pem\ + --rekor_server http://localhost:3000 + Created entry at index 102, available at: http://localhost:3000/api/v1/log/entries/688f817bb1e7cb1b28eadf173b0095724cce86ab0116b0df5a0c8e06c00e880c + $ + $ rekor-cli get --log-index 102 --rekor_server http://localhost:3000 + LogID: e0f8a8ff472431bda298489c292f33f5d30363949df58d2e35c5195f915c7069 + Index: 102 + IntegratedTime: 2022-03-12T13:51:30Z + UUID: 688f817bb1e7cb1b28eadf173b0095724cce86ab0116b0df5a0c8e06c00e880c + Body: { + "RekordObj": { + "data": { + "hash": { + "algorithm": "sha256", + "value": "4a837db6d6a21a9bdfccff6ca21f72d1d4a671b59a5df76158629ff5f6b22ddf" + } + }, + "signature": { + "content": "MEYCIQD4HWtXfSDGpWUUmk1tWUP/V5MRUPgwrUMiiJB7miKZcQIhAJDYUO+lyGYKShCtt3AZZilZkoLEm9WAaXhlzGVwZMu6", + "format": "x509", + "publicKey": { + "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURKakNDQXN1Z0F3SUJBZ0lVSjZVT041dys0UTNYcEk4UXppMEpOVUNjcUI0d0NnWUlLb1pJemowRUF3SXcKUkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjRZVzF3YkdVeApGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUI0WERUSXlNRE14TWpFek5EWXdObG9YRFRJeU1EUXhNVEV6Ck5EWXdObG93UkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjQKWVcxd2JHVXhGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowRApBUWNEUWdBRW5TcGRUTi9VK3BwMk1sbVdPMFFTQUFNOHdObENXTUg3S3UzN0RaWFF6bjFpNXZpdXZuWnJPd3hFCnFzcERWODhabzhteHpRVWhvcmdNVUJNTTJaK1A2cU9DQVprd2dnR1ZNSUlCa1FZREtnTUVCSUlCaUF5Q0FZUXYKT1dvdk5FRkJVVk5yV2twU1owRkNRVkZCUVVGUlFVSkJRVVF2TW5kQ1JFRkJUVU5CWjBsRFFXZE5RMEZuU1VSQgpkMDFFUWtGWlJVSkJVVVZDUVdkSFFtZFZSME5SWjB0RFoydEpRMUZyUzBSQk9FMURaM05QUTNkclNrUlNSVTVFClp6aFJSVUpGVVVObmQxTkZlRWxSUlhjNFVVVkNSQzh5ZDBKRVFWRk5SRUYzVVVSQ1FXZEZRa0ZuVVVOM2EweEYKUWtGUlJVSkJVVVZDUVZGRlFrRlJSVUpCVVVWQ1FWRkZRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkJVVVZDUVZGRgpRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkVMM2RCUVZKRFFVRlJRVUpCUkVGU1JVRkJhRVZDUVhoRlFpODRVVUZHClVVRkNRVkZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdvdmVFRkJWVVZCUlVGQlFVRkJRVUZCUVVGQlFVRkIKUVVGQlFVRkJRUzg0VVVGR1owVkNRVkZGUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdOS0x6aFJRVVpDUlVKQgpRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZRTDJGQlFYZEVRVkZCUTBWUlRWSkJSRGhCYmxKRVIzRlpRVUZFCkx5OWFNQW9HQ0NxR1NNNDlCQU1DQTBrQU1FWUNJUUR1N29IV0hPaW55dDFVdFlMK0loMlVIYkV4a2RZK2FKbjEKMWRySjlMeFRVd0loQU0wSW1NVno2S0dQakpVR3pGeHdaYXJkbFBBNFdlejN4eldZNjNWZkkrdkYKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" + } + } + } + } + +Of interest here is the public key: + + $ echo "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURKakNDQXN1Z0F3SUJBZ0lVSjZVT041dys0UTNYcEk4UXppMEpOVUNjcUI0d0NnWUlLb1pJemowRUF3SXcKUkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjRZVzF3YkdVeApGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUI0WERUSXlNRE14TWpFek5EWXdObG9YRFRJeU1EUXhNVEV6Ck5EWXdObG93UkRFVE1CRUdDZ21TSm9tVDhpeGtBUmtXQTJOdmJURVhNQlVHQ2dtU0pvbVQ4aXhrQVJrV0IyVjQKWVcxd2JHVXhGREFTQmdOVkJBTU1DMlY0WVcxd2JHVXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowRApBUWNEUWdBRW5TcGRUTi9VK3BwMk1sbVdPMFFTQUFNOHdObENXTUg3S3UzN0RaWFF6bjFpNXZpdXZuWnJPd3hFCnFzcERWODhabzhteHpRVWhvcmdNVUJNTTJaK1A2cU9DQVprd2dnR1ZNSUlCa1FZREtnTUVCSUlCaUF5Q0FZUXYKT1dvdk5FRkJVVk5yV2twU1owRkNRVkZCUVVGUlFVSkJRVVF2TW5kQ1JFRkJUVU5CWjBsRFFXZE5RMEZuU1VSQgpkMDFFUWtGWlJVSkJVVVZDUVdkSFFtZFZSME5SWjB0RFoydEpRMUZyUzBSQk9FMURaM05QUTNkclNrUlNSVTVFClp6aFJSVUpGVVVObmQxTkZlRWxSUlhjNFVVVkNSQzh5ZDBKRVFWRk5SRUYzVVVSQ1FXZEZRa0ZuVVVOM2EweEYKUWtGUlJVSkJVVVZDUVZGRlFrRlJSVUpCVVVWQ1FWRkZRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkJVVVZDUVZGRgpRa0ZSUlVKQlVVVkNRVkZGUWtGUlJVSkVMM2RCUVZKRFFVRlJRVUpCUkVGU1JVRkJhRVZDUVhoRlFpODRVVUZHClVVRkNRVkZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdvdmVFRkJWVVZCUlVGQlFVRkJRVUZCUVVGQlFVRkIKUVVGQlFVRkJRUzg0VVVGR1owVkNRVkZGUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZCUVdOS0x6aFJRVVpDUlVKQgpRVUZCUVVGQlFVRkJRVUZCUVVGQlFVRkJRVUZRTDJGQlFYZEVRVkZCUTBWUlRWSkJSRGhCYmxKRVIzRlpRVUZFCkx5OWFNQW9HQ0NxR1NNNDlCQU1DQTBrQU1FWUNJUUR1N29IV0hPaW55dDFVdFlMK0loMlVIYkV4a2RZK2FKbjEKMWRySjlMeFRVd0loQU0wSW1NVno2S0dQakpVR3pGeHdaYXJkbFBBNFdlejN4eldZNjNWZkkrdkYKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" | base64 -d > logged-cert.pem + $ diff cert.pem logged-cert.pem + $ + +As you can see, it is the same certificate that contains our JPG image. Any +other data could be encoded as well using the above trick. |