From e015c42a99f9bfa11945488a154b7e27d50d2335 Mon Sep 17 00:00:00 2001 From: Adrian H Date: Sun, 16 Feb 2020 15:30:38 -0800 Subject: [PATCH 1/5] Timestamping Content two scholarly articles about timestamping methods that are decentralized and trustless. --- timestamping.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 timestamping.txt diff --git a/timestamping.txt b/timestamping.txt new file mode 100644 index 0000000..83d7539 --- /dev/null +++ b/timestamping.txt @@ -0,0 +1,18 @@ +Document robustness of Keybase timestamps under various threat models #3489 + +Finding a side by side comparison of timestamping is difficult, however, I found two scholarly articles about Timestamping. +One of them includes a method of trustless decentralized unalterable timestamping using the Bitcoin blockchain. Here are +the links to the articles from Google Scholar: + + +DESIGN OF A SECURE TIMESTAMPING SERVICE +WITH MINIMAL TRUST REQUIREMENT + +https://drive.google.com/file/d/1Dvgw2aDpqPp32Vu2B-tqzJLzhsl1JWZV/view?usp=sharing + +Decentralized Trusted Timestamping using the Crypto Currency Bitcoin + +https://drive.google.com/file/d/1ucU4C2Amys_igS0ylWMmKNtDUPwAf7AD/view?usp=sharing + +As far as keybase goes, from the research that I did, the disarray of the documentation makes me wonder about the state of +the product. :-/ From 830e0e2e7d9dacd43e2f6ecade831967a5686e96 Mon Sep 17 00:00:00 2001 From: Adrian H Date: Sun, 16 Feb 2020 17:50:08 -0800 Subject: [PATCH 2/5] updated information to contain keybase spec Updated content --- timestamping.md | 34 ++++++++++++++++++++++++++++++++++ timestamping.txt | 18 ------------------ 2 files changed, 34 insertions(+), 18 deletions(-) create mode 100644 timestamping.md delete mode 100644 timestamping.txt diff --git a/timestamping.md b/timestamping.md new file mode 100644 index 0000000..cadd13f --- /dev/null +++ b/timestamping.md @@ -0,0 +1,34 @@ +# Keybase Security Evaluation: + +## Past Security Issues: + +KB001: Local Privilege Escalation in MacOS Clients Before v2.5.2 (2018.12.18) +KB002: Local Privilege Escalation in Linux Clients Between v2.3.0 and v2.8.0-20181017144748 (2018.12.18) +KB003: Buffer overflow in Windows filesystem driver before v2.12.3 (2018.12.25) +KB004: Local Privilege Escalation in MacOS Clients Before v2.12.6 (2019.01.30) + +Mac and Linux, both being linux based at the command line, seem to be vulnerable to local privilege escalations. Windows has had a buffer overflow security issue in the past. + +[Keybase Server Security Overview](https://keybase.io/docs/server_security) + +The keybase filesystem (KBFS) Threat Model does assume the security of the Go Implementation of the NaCl cryptographic library. Assumed security could be risky, I would want more information, but can't find any. + +# Keybase "Risk of Data Loss" as stated in the [KBFS Documentation](https://keybase.io/docs/kbfs) + +At the time of this document, there are very few people using this system. We're just getting started testing. Note that we could, hypothetically, lose your data at any time. Or push a bug that makes you throw away your private keys. Ugh, burn. + +So as one of our first testers: back up anything you put into Keybase's alpha, and remember: we can't recover lost encrypted data. + +Also, if you throw away all your devices, you will lose your private data. Your encrypted data is ONLY encrypted for your device & paper keys, not any PGP keys you have. + +# Performance + +We've made no performance optimizations yet. There's a lot of low-hanging fruit. + +# NCC Group Protocol Security Review for Keybase found here: + +https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf + +High Risk Issues - 1 +Medium Risk Issues - 3 +Los Risk Issues - 1 diff --git a/timestamping.txt b/timestamping.txt deleted file mode 100644 index 83d7539..0000000 --- a/timestamping.txt +++ /dev/null @@ -1,18 +0,0 @@ -Document robustness of Keybase timestamps under various threat models #3489 - -Finding a side by side comparison of timestamping is difficult, however, I found two scholarly articles about Timestamping. -One of them includes a method of trustless decentralized unalterable timestamping using the Bitcoin blockchain. Here are -the links to the articles from Google Scholar: - - -DESIGN OF A SECURE TIMESTAMPING SERVICE -WITH MINIMAL TRUST REQUIREMENT - -https://drive.google.com/file/d/1Dvgw2aDpqPp32Vu2B-tqzJLzhsl1JWZV/view?usp=sharing - -Decentralized Trusted Timestamping using the Crypto Currency Bitcoin - -https://drive.google.com/file/d/1ucU4C2Amys_igS0ylWMmKNtDUPwAf7AD/view?usp=sharing - -As far as keybase goes, from the research that I did, the disarray of the documentation makes me wonder about the state of -the product. :-/ From 7e205b6a24fd06ab1de599c44f5b670a81507f06 Mon Sep 17 00:00:00 2001 From: Adrian H Date: Sun, 16 Feb 2020 18:26:47 -0800 Subject: [PATCH 3/5] Update timestamping.md --- timestamping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/timestamping.md b/timestamping.md index cadd13f..01f79f4 100644 --- a/timestamping.md +++ b/timestamping.md @@ -31,4 +31,4 @@ https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019- High Risk Issues - 1 Medium Risk Issues - 3 -Los Risk Issues - 1 +Low Risk Issues - 1 From 9480a0fd46da2bf8e97c562174c574ffb6eb1b1a Mon Sep 17 00:00:00 2001 From: Adrian H Date: Sun, 16 Feb 2020 18:35:12 -0800 Subject: [PATCH 4/5] added content added content --- timestamping.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/timestamping.md b/timestamping.md index 01f79f4..1893c66 100644 --- a/timestamping.md +++ b/timestamping.md @@ -21,10 +21,28 @@ So as one of our first testers: back up anything you put into Keybase's alpha, a Also, if you throw away all your devices, you will lose your private data. Your encrypted data is ONLY encrypted for your device & paper keys, not any PGP keys you have. +# Security Model + +At a high level, end-user devices are trusted and Keybase/KBFS/other servers are untrusted. On desktops, we run all KBFS processes as the current user and use OS-level secret stores, **but we don’t attempt to protect against other processes owned by the same user or root.** <------------------------ That's risky and could open keybase up to potential tampering, perhaps if system time is adjusted and the computer is offline. + +The KBFS client doesn’t trust any data coming from Keybase or KBFS servers, and verifies any received data against the relevant users’ public keys. For the nitty-gritty details, see the KBFS crypto doc. In particular, the KBFS servers cannot see into the contents or structure of your (non-public) files. + +That having been said, the KBFS servers know what users can access which data, and will only serve data to an authorized reader of a TLF with a valid session. Furthermore, they will only serve historical (archived) data to writers of a TLF, even public ones. + +Each TLF is backed by an "implicit" Keybase team, and the private keys required to access the TLF are managed by this team; see the Keybase team docs for more details. When you provision a new device to your account, it automatically gains access to these keys, and thus the TLF data. When you revoke a device, a new key is created for the TLF and used to encrypt all future data written to the TLF, to ensure that the device cannot read the new data. Old data is not re-encrypted (though our servers won’t serve it to revoked devices). + +# Another Security Disclaimer Pointing out "At your own Risk" + +If you download something off of Keybase.pub, you're trusting (a) Keybase over https, and (b) that someone hasn't hacked into Keybase.pub. So it's a great site to explore, but if you're downloading something crucial such as a copy of the latest libssl or bitcoind or GPG Tools Suite.dmg from a friend, you should really just look in /keybase/public on your own computer. That will verify all the crypto and guarantee you're seeing the same signed bits they are. And it's easier. + # Performance We've made no performance optimizations yet. There's a lot of low-hanging fruit. +## Running on a resource-constrained system + +On desktops and laptops, KBFS makes liberal use of memory in order to cache recently-read data for performance. It also uses CPU and networking resources to pre-fetch data you are likely to access in the near future, such as recently-edited files or subsequent data blocks to data that was just requested. These optimization tradeoffs might not be desired on systems that don't have any extra RAM or CPU to spare. + # NCC Group Protocol Security Review for Keybase found here: https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf From d350f40e4e6cc63003c3e478d5d52f930e577494 Mon Sep 17 00:00:00 2001 From: Adrian H Date: Sun, 16 Feb 2020 18:51:27 -0800 Subject: [PATCH 5/5] updated content updated content --- timestamping.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/timestamping.md b/timestamping.md index 1893c66..0ce71dc 100644 --- a/timestamping.md +++ b/timestamping.md @@ -43,6 +43,31 @@ We've made no performance optimizations yet. There's a lot of low-hanging fruit. On desktops and laptops, KBFS makes liberal use of memory in order to cache recently-read data for performance. It also uses CPU and networking resources to pre-fetch data you are likely to access in the near future, such as recently-edited files or subsequent data blocks to data that was just requested. These optimization tradeoffs might not be desired on systems that don't have any extra RAM or CPU to spare. +# 🚀 Keybase is now writing to the Stellar blockchain 🚀 <<---- it's blockchain based anyhow! ...... + +Every public announcement you make on Keybase is now verifiably signed by Keybase and hashed into the Stellar blockchain. To be specific, all of these: + +announcing your Keybase username +adding a public key +identity proofs (twitter, github, your website, etc.) +public bitcoin address announcements +public follower statements +revocations! +team operations +Quick background +Earlier, in the server security overview we described Keybase's approach to server security: (1) each user has his or her own signature chain that grows monotonically with each announcement; (2) the server maintains a global Merkle Tree that covers all signature chains; and (3) the server signs and publishes the root of the Merkle Tree with every new user signature. This configuration strongly discourages the server from lying by omission, since clients have the tools to catch the server in the act. + +There was one point we glossed over. A sophisticated adversary Eve could commandeer our server and fork it, showing Alice and Bob different versions of server state. Eve could get away with her attack as long as she never tries to merge Alice and Bob's views back together, and as long as they don't communicate out-of-band. (See Mazières and Shasha for a formal treatment of fork-consistency). + +Enter the Stellar Blockchain +Thanks to Stellar, we are unforkable. + +Since 20 Jan 2020, Keybase has been regularly pushing its Merkle Root into the Stellar blockchain, signed by the key GA72FQOMHYUCNEMZN7GY6OBWQTQEXYL43WPYCY2FE3T452USNQ7KSV6E. Now, Alice and Bob can consult the blockchain to find a recent root of the Keybase Merkle tree. Unless Eve can fork the Stellar blockchain, Alice and Bob will see the same value, and can catch Eve if she tries to fork Keybase. + +Another way to think of this property is to turn it on its head. Whenever Alice uploads a signed announcement to the Keybase servers, she influences Keybase's Merkle Tree, which in turn influences the Stellar blockchain, which in turn Bob can observe. When Bob observes changes in the Stellar blockchain, he can work backwards to see Alice's change. There's little Eve can do to get in the way without being detected. + +You Mean My Signatures affect a Major Cryptocurrency Blockchain? + # NCC Group Protocol Security Review for Keybase found here: https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf