├── .gitignore ├── README.md ├── code ├── Makefile ├── README.md ├── all_keys_to_hex.py ├── collect_all_Tor_rsa_keys.py ├── itos │ ├── hsdirs.csv │ ├── itos.go │ ├── itos_test.go │ └── onion-services.csv └── vulnerable_key_data_to_csv.py ├── paper ├── Makefile ├── abstract.tex ├── acknowledgements.tex ├── appendix.tex ├── background.tex ├── conclusion.tex ├── discussion.tex ├── introduction.tex ├── llncs.cls ├── main.tex ├── method.tex ├── references.bib ├── related.tex ├── results.tex └── splncs03.bst └── web ├── anomalous-tor-keys.bib ├── bibliography ├── author.html ├── author_reverse.html ├── bibtex.html ├── index.html ├── pdf ├── year.html └── year_reverse.html ├── data ├── anomalous-keys.tar.xz └── targeted-onion-services.tar.xz ├── img ├── claudia.png ├── george.png ├── laura.png ├── paper-thumb.png └── philipp.png ├── index.html └── pdf ├── Bernstein04.pdf ├── Bernstein2013a.pdf ├── Biryukov2013a.pdf ├── Boneh1999a.pdf ├── Coppersmith1996a.pdf ├── Coppersmith1997a.pdf ├── Goldberg2013a.pdf ├── Hastings2016a.pdf ├── Heninger2012a.pdf ├── Jansen2012a.pdf ├── Lenstra2012a.pdf ├── Matic2015a.pdf ├── Valenta2016a.pdf ├── Winter2016a.pdf ├── anomalous-tor-keys.pdf └── rivest1978.pdf /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | We have just published a (not yet peer-reviewed) technical report entitled "Anomalous keys in Tor relays." https://nymity.ch/anomalous-tor-keys/ 2 | 3 | The project was inspired by the "Mining Your P's and Q's" paper from Heninger et. al., and in it, we take a closer look at the RSA keys used in Tor since 2005. We found that entities had purposely created anomalous keys in order to attack Tor's onion services and that researchers had inadvertently created weak keys while conducting experiments on Tor. (None of the weak keys we found are affecting the current Tor network.) 4 | 5 | We welcome your questions and feedback! 6 | 7 | 8 | Regards, 9 | George, Claudia, Laura, & Philipp 10 | -------------------------------------------------------------------------------- /code/Makefile: -------------------------------------------------------------------------------- 1 | CFLAGS=-std=c99 -Wall -O4 -pthread -I./gmp-patched/include/ -Dmpz_raw_64 2 | LDFLAGS=./gmp-patched/lib/libgmp.a 3 | 4 | fastgcd: fastgcd.c 5 | $(CC) $(CFLAGS) $? $(LDFLAGS) -o $@ 6 | 7 | -------------------------------------------------------------------------------- /code/README.md: -------------------------------------------------------------------------------- 1 | ## Instructions for running the weak-tor-keys detection code. 2 | 3 | Using a Linux machine: 4 | 5 | 1. `wget https://factorable.net/fastgcd-1.0.tar.gz` 6 | 2. Unzip the file and replace the Makefile with the one found in this code repository. 7 | 3. Follow the install instructions in the fastgcd README 8 | 4. Create a directory called archived_descriptors. This directory should contain all unzipped archived Tor relay descriptors https://collector.torproject.org/archive/relay-descriptors/server-descriptors/. 9 | 5. Run `python collect_all_tor_rsa_keys.py` 10 | * This will output two files: 11 | * all_public_keys.txt (all of the Tor RSA public keys) 12 | * All_TOR_RSA_Key_Data.pck (a pickled python dictionary with all of the Tor RSA public key metadata). 13 | * Note: this will take more than 24 hours to run if you are running on all archived Tor relay descriptors. 14 | 6. Manually clean up all_public_keys.txt by searching for the string “onion.” Delete malformed lines. 15 | 7. Run `python all_keys_to_hex.py` 16 | * This will output two files: 17 | * all_hex_keys.txt (unique list of all RSA public key moduli, in hex) 18 | * All-Hex-To-RSA.pck (a python pickled dictionary that maps hex moduli to a list of dictionaries. Each sub-dictionary contains an RSA public key and its exponent. All-Hex-To-RSA.pck will catch moduli that map to more than one RSA public key). 19 | 8. Run `./fastgcd all_hex_keys.txt` 20 | * This will output two files: 21 | * vulnerable_moduli 22 | * gcds 23 | * Please refer to fastgcd README for descriptions of each. 24 | 9. Run `python vulnerable_key_data_to_csv.py` 25 | * This outputs two files: 26 | * all_vulnerable_key_data.csv (csv file containing all keys with shared GCD and their corresponding metadata) 27 | * all_repeated_moduli_data.csv (csv file containing all keys with repeated moduli and their corresponding metadata and exponent) 28 | -------------------------------------------------------------------------------- /code/all_keys_to_hex.py: -------------------------------------------------------------------------------- 1 | """ 2 | For each RSA public key, extract its hex modulo and exponent. Create 3 | a dictionary mapping each hex modulo to a list of dictionaries. Each 4 | sub-dictionary contains an RSA public key and its exponent. Pickle 5 | that map. 6 | """ 7 | from collections import defaultdict 8 | from base64 import b64decode 9 | import pickle 10 | 11 | from Crypto.PublicKey import RSA 12 | 13 | 14 | all_public_keys = open('all_public_keys.txt', 'r') 15 | all_hex_keys = open('all_hex_keys.txt', 'w') 16 | 17 | hex_to_b64 = defaultdict(list) 18 | for key64 in all_public_keys : 19 | keyDER = b64decode(key64.replace('\n', '')) 20 | keyPub = RSA.importKey(keyDER) 21 | hex = hex(keyPub.n, 'x') 22 | exp = keyPub.e 23 | 24 | # Write each unique hex to all_hex_keys.txt 25 | if hex not in hex_to_b64: 26 | all_hex_keys.write(hex + '\n') 27 | 28 | hex_to_b64[hex].append({ 29 | 'rsa_pub_key': key64, 30 | 'exponent': exp 31 | }) 32 | 33 | pickle.dump(hex_to_b64, open('All-Hex-To-RSA.pck', 'wb')) 34 | 35 | -------------------------------------------------------------------------------- /code/collect_all_Tor_rsa_keys.py: -------------------------------------------------------------------------------- 1 | """ 2 | Collect all RSA public keys: recent, archived, signing key, and onion key. 3 | Create a dictionary that maps RSA public keys to metadata. Pickle that 4 | dictionary. 5 | """ 6 | import pickle 7 | 8 | from stem.descriptor.remote import DescriptorDownloader 9 | from stem.descriptor.reader import DescriptorReader 10 | 11 | 12 | rsa_key_data = {} 13 | 14 | # Get RSA keys from recent server descriptors. 15 | downloader = DescriptorDownloader() 16 | for desc_r in downloader.get_server_descriptors(): 17 | # Load metadata with relay information: nickname, fingerprint, published, 18 | # address, or_port, platform, contact, average_bandwith, extra_info_digest 19 | metadata = {} 20 | if desc_r.nickname is not None: 21 | metadata['nickname'] = desc_r.nickname 22 | if desc_r.fingerprint is not None: 23 | metadata['fingerprint'] = desc_r.fingerprint 24 | if desc_r.published is not None: 25 | metadata['date'] = desc_r.published 26 | if desc_r.address is not None: 27 | metadata['ip4_address'] = desc_r.address 28 | if desc_r.or_port is not None: 29 | metadata['port'] = desc_r.or_port 30 | if desc_r.platform is not None: 31 | metadata['platform'] = desc_r.platform 32 | if desc_r.contact is not None: 33 | metadata['contact'] = desc_r.contact 34 | if desc_r.average_bandwidth is not None: 35 | metadata['bandwidth'] = desc_r.average_bandwidth 36 | if desc_r.extra_info_digest is not None: 37 | metadata['extra'] = desc_r.extra_info_digest 38 | 39 | onion_metadata = metadata.copy() 40 | 41 | pubKey = desc_r.signing_key 42 | if pubKey is not None: 43 | pubKey = pubKey.replace('\n', '') 44 | pubKey = pubKey.replace('-----BEGIN RSA PUBLIC KEY-----', '') 45 | pubKey = pubKey.replace('-----END RSA PUBLIC KEY-----', '') 46 | metadata['key_type'] = 'signing key' 47 | rsa_key_data[pubKey] = metadata 48 | 49 | onionKey = desc_r.onion_key 50 | if onionKey is not None: 51 | onionKey = onionKey.replace('\n', '') 52 | onionKey = onionKey.replace('-----BEGIN RSA PUBLIC KEY-----', '') 53 | onionKey = onionKey.replace('-----END RSA PUBLIC KEY-----', '') 54 | onion_metadata['key_type'] = 'onion key' 55 | rsa_key_data[onionKey] = onion_metadata 56 | 57 | # Get RSA keys from archived server descriptors. 58 | descriptors = ['archived_descriptors/'] 59 | with DescriptorReader(descriptors) as reader: 60 | for desc_a in reader: 61 | metadata = {} 62 | if desc_a.nickname is not None: 63 | metadata['nickname'] = desc_a.nickname 64 | if desc_a.fingerprint is not None: 65 | metadata['fingerprint'] = desc_a.fingerprint 66 | if desc_a.published is not None: 67 | metadata['date'] = desc_a.published 68 | if desc_a.address is not None: 69 | metadata['ip4_address'] = desc_a.address 70 | if desc_a.or_port is not None: 71 | metadata['port'] = desc_a.or_port 72 | if desc_a.platform is not None: 73 | metadata['platform'] = desc_a.platform 74 | if desc_a.contact is not None: 75 | metadata['contact'] = desc_a.contact 76 | if desc_a.average_bandwidth is not None: 77 | metadata['bandwidth'] = desc_a.average_bandwidth 78 | if desc_a.extra_info_digest is not None: 79 | metadata['extra'] = desc_a.extra_info_digest 80 | 81 | onion_metadata = metadata.copy() 82 | 83 | pubKey = desc_a.signing_key 84 | if pubKey is not None: 85 | pubKey = pubKey.replace('\n', '') 86 | pubKey = pubKey.replace('-----BEGIN RSA PUBLIC KEY-----', '') 87 | pubKey = pubKey.replace('-----END RSA PUBLIC KEY-----', '') 88 | metadata['key_type'] = 'signing key' 89 | rsa_key_data[pubKey] = metadata 90 | 91 | onionKey = desc_a.onion_key 92 | if onionKey is not None: 93 | onionKey = onionKey.replace('\n', '') 94 | onionKey = onionKey.replace('-----BEGIN RSA PUBLIC KEY-----', '') 95 | onionKey = onionKey.replace('-----END RSA PUBLIC KEY-----', '') 96 | onion_metadata['key_type'] = 'onion key' 97 | rsa_key_data[onionKey] = onion_metadata 98 | 99 | with open('all_public_keys.txt', 'w') as f: 100 | for key in rsa_key_data: 101 | f.write(key + '\n') 102 | 103 | pickle.dump(rsa_key_data, open( 'All_TOR_RSA_Key_Data.pck', 'wb' ) ) 104 | 105 | -------------------------------------------------------------------------------- /code/itos/hsdirs.csv: -------------------------------------------------------------------------------- 1 | 2249E809844974F778883BBD8BF0A52E454906BC,16283,16297 2 | 2249EB42F11C1CD46C5D4F8208F8A6D82F0F7DBA,16283,16297 3 | 2249EC7894F29AC72DAE80B114C0B25CC3CB6889,16283,16297 4 | 264EA1284855A596D5D642CEE878A211A221FF66,17135,17145 5 | 264EA12B47CBCC8043C549D540828B624656AEB3,17135,17144 6 | 264EA12B4C46672E002C07290B43691DBA5FA9D6,17135,17144 7 | 26597E61DDFEE78F336DFA2F97EBF300A6699DE8,17129,17143 8 | 26597E62875C498AC139109EC25489AD6D7CA414,17129,17143 9 | 26597E62FBB33D8E76C5ADA8E5CAD43826515C55,17129,17136 10 | 2D04AF7C9DC68C75C90B57CF774ADC4B4528EAF3,17046,17046 11 | 2D148D3D88D454B0D306F429FA27C0400FCA0C8C,17129,17135 12 | 2D148D3EBF9D2B9D8CCB3F10B43DC3B2046C7C27,17129,17139 13 | 2DFDC2BA32DC2A2BBBF50BC6752873B785401692,16666,16666 14 | 2E25D8447518DA93B4FF3597192A93832917C937,17135,17144 15 | 2E25D8454C96E20CF1536DE6AEE4AC8B81E7114D,17135,17144 16 | 2E25D846564DCBE43CD273E9306866DCDA8365EA,17135,17197 17 | 2E25D8469331FEAE933D08A3055E5ABD15E855E9,17135,17143 18 | 2E25D847E579AED1B0ECAB7AA78CA4F44E337626,17135,17145 19 | 325CAC0A43B2121B81CD66E94A5027F1C8C97172,16659,16678 20 | 325CAC0AB1AAD27493B9D06DC7F497D4F22A0AB4,16659,16678 21 | 325CAC0B7FA8CD77E39D8068207D0D6B10EA1317,16659,16678 22 | 32E71B90DA1CCEC7C68B92EC1097A3EBE632E03A,17128,17129 23 | 36043967166B5F365194C57DF8FC07C54A52EDEC,16881,16898 24 | 37D5E568832B3BAA68E6875AD801C1E3ACED9A51,16729,16736 25 | 37D5E5688CEB59A45976B33B0B2D2A981FE770C6,16729,16736 26 | 37D5E5689CA4F9D5B5988811C1C68BEAB787A96F,16729,16730 27 | 38FCC60412A88EB83EA3C8E1E70FFE1B55DF0A77,15776,15838 28 | 3968276F7A4AC45215BD9991AF92EDA6B09CE1F6,17128,17129 29 | 410BA17E011139CC5138EA57EC3B7B2166F62007,16283,16297 30 | 410BB96218A5BB8BE18FCBB1BD8FF9AA5D748122,16283,16297 31 | 410BCDC191A0151603CE0E87C08BA0934738FD72,16283,16297 32 | 51FC178DFF3D0B869760F5740681A40D783CAD34,15857,15867 33 | 5282013126B3D18E9C91ED8A0F1D914C4F1EB2A9,15853,15867 34 | 5404DC1604772840890937D378F9C7B1B520C4AF,17129,17129 35 | 59529817C6E797D78311061180276BBC26025E1D,15853,15867 36 | 59E415D45E3D7EBAD6D62E995B5C4D0B3A15C879,17129,17140 37 | 59E415D4FE1738927E24E8C54C5C12111833DABC,17129,17157 38 | 59E415D78921BFF88168DB65D6230D68466436AE,17129,17140 39 | 63A8D7D54CB7BB480C68941E25B8140BC48A118D,15673,15673 40 | 6761D2BCA1D8C6C70DBAB04E839D85CEA0D007DC,17129,17197 41 | 6761D2BCECD947E7C1B3329F9DE869E9E80C983C,17129,17135 42 | 6761D2BE758FA0D7682240A9BC39E999DF2D2B97,17129,17140 43 | 712CA45AF4055E7AC69A299B2F11C8E7112E8D0E,15844,15852 44 | 71363B816E622EDA82310AD5CC7112D2F1A3DD47,17128,17129 45 | 71363B83B25829A3CD10F0D74F50B1D4AB58C8AC,17128,17129 46 | 739758B1AB48D6039DCE45C1872FC41568A9845E,13892,13900 47 | 7CDB224E9BCFEDFD6BD6CBD6D25D9AD7FD3015FF,17129,17134 48 | 7CDB224FE64F2A50CC508553CF91B2A1A2A89071,17129,17143 49 | 816FEE14FC01EA6ACF287CACB738AC394CEE63AF,16666,16678 50 | 816FEE15A68F015DA7340F56451A160631DB4E2B,16666,16678 51 | 816FEE16200BE1719D00BCA35AA94329B668EF3A,16666,16678 52 | 838A296A72D20A08D30EB5611857D5EE2BBDCA8A,16283,16297 53 | 838A305F8D47EAEB420522F2822F3E0A1A15C20D,16283,16297 54 | 838A71E2BA938A3BE4DB564413A6046A4B66C534,16283,16297 55 | 8808B01B7B7450729A93F07BDB983ED3FE5F36BF,16192,16336 56 | 8E1600DD28FB6CF9DEB4B732B07748FBF56A0091,15774,15774 57 | 8FF3ED2EC73DB941BF0B0510BC403185D0CC1FDC,16903,16927 58 | 8FF3ED2F3E64A6DC27308DB4A7F8082B653DE2EB,16896,16938 59 | 905CC77C4B81CF9D387B7075EE3483A2571F8725,17128,17129 60 | 90645A9B96FEE92D87889782E58E11D3022DA622,16659,16659 61 | A0E83AA0E24EC60E1E84977864319F6594B63267,17128,17139 62 | A0E83AA191220B240EC042A4231FACE0C0BA5A6A,17128,17136 63 | A0E83AA28382135DC8397928194AC0459116E0AA,17128,17136 64 | A574E18E99C8FD071BBB8E87424C5144FCA8B200,16253,16258 65 | A5C59B3D0FFBDE88405E61816B5AA16C5C12A827,16659,16666 66 | A5C59B3FCCD2FA8FAD42BF046E127AA239BD0852,16659,16666 67 | A5C59B3FD5625A0D85D10B4CF7FE801262EBEF11,16659,16666 68 | B81B43C015DE42D0520895B0076BDB40506CA46B,15853,15857 69 | BC79109C0070A5881D2FE0515F063D1A525929B0,16714,16719 70 | BC79109C1DAB5E9E40CC0D8E84D11600417D3D84,16714,16719 71 | BC89A92F53581C4F616987F292CD336E7B42B81B,15844,15848 72 | BCB332864640653892D4CD4B7CE10072BBA1737D,15857,15867 73 | BE6FFBA535E97CB94199DA4E62F758301903BD03,16412,16429 74 | BE6FFBDAE074942B57A547FDB21E5F7DB7087D9C,16412,16429 75 | C722E7E9E23D9DCA2617648A54BAA8C4363D7989,16927,16938 76 | CF45F18FC11C457E721D3091BB7D09555B9D107D,16881,16928 77 | D271E035672E3FB59A2E4EBF4C7DE3DD31CD314F,17129,17129 78 | D4073DE6C5DB04D61AD98F672832CD31B88569FC,16682,16684 79 | DE15299D7EE5882F0BEF5F5945ECF1A97C1B6D93,15844,15852 80 | DE2702F445CA7482747F065C43C463FCD5441BFD,17129,17135 81 | DE2702F4B687B23D8E3E77D7FFE849EE076003C4,17129,17137 82 | DE2702F4E5863F58211ADBD9EFF303ADD2595124,17128,17135 83 | E038CACD70D6014A5C9039617E071536F59D44E0,15774,15774 84 | E038CBE7AFFFAC41E30F25D1FB98F3EC89A9A551,15774,15776 85 | E1EF8985FB25DEA2D6F9FEA8F368DD217850EB64,16283,16297 86 | E1EF9EB8D05DDB238FDBA274602A568D9DEA3179,16283,16297 87 | E1EFA388B9E6C4C91696822C5BBEC651A94E36D6,16283,16297 88 | E5E778306D4BA8342A878ABB898E57D2FCD09151,16659,16665 89 | E5E7783135A1AC4CCEF9CFDEF8D7FF85C8EC5D03,16659,16666 90 | E5E778326AF0FF0A634AD3A796E61C6C78DFA2B2,16659,16666 91 | E9F25C4899F9DC81E48E02637C479C4DD9D37810,15853,15857 92 | EBF154D8BB6EECCC2921FC50050AE6ED9EF60CD2,17128,17137 93 | EBF154D9E2B10A2420E052AEBB30E15B7EE4F523,17128,17143 94 | EBF154DA21B49101ED5B2146B8D28EADAC1E8DB9,17128,17135 95 | F5079E2D32CB50FD30EA0F16DFA18E289F890099,17129,17135 96 | F5079E2D5437F7A393C95384D3695F2A8C6D2CBA,17129,17139 97 | F5079E2E462D787A69CD6986107467D11D32C27B,17129,17135 98 | F52D83EF8174CA171F2A548A96497DE979C94A5A,15778,15838 99 | F6961286C453F6A6381DDC72F8DC33C6FCCB620C,16666,16676 100 | F6961286D361F825A9AD7ED4433B71F7897F232C,16666,16678 101 | F6961286D826D7D1C0F96F5FC085110268DD3BA8,16666,16675 102 | F6961286DFF703989083D7DE45787357B5212576,16675,16678 103 | FA0BDA0E2571E5FD388076ADC97AB267DB8D7984,16729,16731 104 | FA0BDA0E28E56247266A7F14672619666455993B,16729,16731 105 | FA0BDA0E3F12D2CBEDE0D372668E07BE120511E1,16729,16736 106 | FA2567404D560A4C8ECE7DEBC805E1DABE129E59,16659,16675 107 | FA256741ED22FD96AF5A11924F7431EE9B2469B0,16660,16665 108 | FA256743ACFCA9B7C85DCCD2BCC3091EAA8E32B5,16659,16675 109 | FC360E29137DB39F194F4557C60096E2749BD079,16757,16762 110 | FF0BF54FBEEE7A003CE6F359D09689F725E2F3ED,15848,15852 111 | -------------------------------------------------------------------------------- /code/itos/itos.go: -------------------------------------------------------------------------------- 1 | // itos is short for "identifying targeted onion services." It takes as input 2 | // a set of onion services and malicious HSDirs, and tries to figure out what 3 | // onion services the HSDirs targeted, by calculating descriptor IDs. 4 | // 5 | // Copyright 2017 Philipp Winter 6 | // 7 | // itos is free software: you can redistribute it and/or modify it under the 8 | // terms of the GNU General Public License as published by the Free Software 9 | // Foundation, either version 3 of the License, or (at your option) any later 10 | // version. 11 | // 12 | // itos is distributed in the hope that it will be useful, but WITHOUT ANY 13 | // WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS 14 | // FOR A PARTICULAR PURPOSE. See the GNU General Public License for more 15 | // details. 16 | // 17 | // You should have received a copy of the GNU General Public License along with 18 | // itos. If not, see . 19 | package main 20 | 21 | import ( 22 | "bufio" 23 | "crypto/sha1" 24 | "encoding/base32" 25 | "encoding/hex" 26 | "flag" 27 | "fmt" 28 | "log" 29 | "os" 30 | "strconv" 31 | "strings" 32 | "time" 33 | ) 34 | 35 | const ( 36 | SimThreshold = 5 // Just a hunch, for now. 37 | SecsPerDay = 86400 // Not a hunch. 38 | Start = 0 39 | End = 1 40 | DefaultStartDate = "2005-01-01" 41 | ) 42 | 43 | // Replicas represents the two numerals that are used to replicate descriptors 44 | // across Tor's hash ring. 45 | var Replicas = []byte{0, 1} 46 | 47 | // AttackedHSes keeps track of onion services that might have been targeted. 48 | var AttackedHSes = make(map[string]struct{}) 49 | 50 | // getTime turns the given Tor-specific, four-byte time period into a 51 | // human-readable string. That helps in figuring out when a malicious HSDir 52 | // targeted a particular descriptor ID. 53 | func getTime(timePeriod [4]uint8) string { 54 | 55 | var t uint32 56 | 57 | t = uint32(timePeriod[3]) 58 | t |= uint32(timePeriod[2]) << 8 59 | t |= uint32(timePeriod[1]) << 16 60 | t |= uint32(timePeriod[0]) << 24 61 | 62 | return fmt.Sprintf("%s", time.Unix(int64(t*SecsPerDay-SecsPerDay), 0)) 63 | } 64 | 65 | // min returns the smaller of the two given values. 66 | func min(len1, len2 int) int { 67 | 68 | if len1 < len2 { 69 | return len1 70 | } else { 71 | return len2 72 | } 73 | } 74 | 75 | // similarity quantifies the distance between a given descriptor ID and HSDir 76 | // ID. The intuition is that the higher the similarity, the more likely that 77 | // the given HSDir was targeting the descriptor. 78 | func similarity(HSDirId, descriptorId string) int { 79 | 80 | descriptorId = strings.ToLower(descriptorId) 81 | HSDirId = strings.ToLower(HSDirId) 82 | 83 | // If HSDir < descriptorId, there's no way it's the attacker. 84 | if strings.Compare(HSDirId, descriptorId) == -1 { 85 | return 0 86 | } 87 | 88 | length := min(len(descriptorId), len(HSDirId)) 89 | for i := 0; i < length; i++ { 90 | if descriptorId[i] != HSDirId[i] { 91 | return i 92 | } 93 | } 94 | return length 95 | } 96 | 97 | // isNastyHSDir attempts to find HSDirs that could have attacked the given 98 | // descriptor ID. We do that by checking if the fingerprint prefix exceeds or 99 | // is equal to our threshold. 100 | func isNastyHSDir(HSDirId, descriptorId, onionService string, timePeriod [4]uint8) bool { 101 | 102 | // Check if descriptor ID is similar to any of our malicious HSDirs. 103 | if similarity(HSDirId, descriptorId) >= SimThreshold { 104 | fmt.Printf("%s,%s,%s,%s\n", HSDirId, descriptorId, 105 | strings.ToLower(onionService), getTime(timePeriod)) 106 | AttackedHSes[onionService] = struct{}{} 107 | return true 108 | } 109 | 110 | return false 111 | } 112 | 113 | // parseHSDirs parses the given CSV file and returns a map that maps relay 114 | // fingerprints to an array that contains the time stamps indicating when the 115 | // relay was first and last online, respectively. 116 | func parseHSDirs(file string) map[string][2]int { 117 | 118 | HSDirs := make(map[string][2]int) 119 | 120 | fd, err := os.Open(file) 121 | if err != nil { 122 | log.Fatalf("Couldn't open HSDirs file because: %s\n", err) 123 | } 124 | defer fd.Close() 125 | 126 | scanner := bufio.NewScanner(fd) 127 | for scanner.Scan() { 128 | line := scanner.Text() 129 | words := strings.Split(line, ",") 130 | n1, n2 := strToInt(words[1]), strToInt(words[2]) 131 | if n1 > n2 { 132 | log.Fatalf("Relay %s: %d cannot be larger than %d.\n", words[0], n1, n2) 133 | } 134 | HSDirs[words[0]] = [2]int{n1, n2} 135 | } 136 | 137 | return HSDirs 138 | } 139 | 140 | // parseHSs parses the given file and returns a slice of onion services. 141 | func parseHSs(file string) []string { 142 | 143 | var HSs []string 144 | 145 | fd, err := os.Open(file) 146 | if err != nil { 147 | log.Fatalf("Couldn't open HSs file because: %s\n", err) 148 | } 149 | defer fd.Close() 150 | 151 | scanner := bufio.NewScanner(fd) 152 | for scanner.Scan() { 153 | line := scanner.Text() 154 | HSs = append(HSs, line) 155 | } 156 | 157 | return HSs 158 | } 159 | 160 | // strToInt converts the given string to an integer. 161 | func strToInt(num string) int { 162 | 163 | i, err := strconv.Atoi(num) 164 | if err != nil { 165 | log.Fatalf("Couldn't convert string to integer because: %s\n", err) 166 | } 167 | 168 | return i 169 | } 170 | 171 | // iterateHSs iterates over the given onion services and checks if any of the 172 | // given HSDirs could have attacked an onion service. The function returns a 173 | // list of HSDirs whose fingerprint is suspiciously close (the threshold is 174 | // determined by SimThreshold) to any onion service's descriptor ID. 175 | func iterateHSs(HSDirs map[string][2]int, HSs []string) []string { 176 | 177 | var nastyHSDirs []string 178 | var descriptorId string 179 | var timePeriod [4]uint8 180 | // The two most significant bytes (in network byte order) never change. 181 | timePeriod[0] = 0 182 | timePeriod[1] = 0 183 | 184 | // CSV header. 185 | fmt.Println("hsdir,desc,onionservice,time") 186 | 187 | allServices := len(HSs) 188 | // Iterate over all onion services we have. Any of them could be a victim. 189 | for i, onionService := range HSs { 190 | 191 | if (i+1)%1000 == 0 { 192 | log.Printf("Processing %d/%d onion services.\n", i+1, allServices) 193 | } 194 | 195 | // Turn onion service string into byte array. 196 | permanentId, err := base32.StdEncoding.DecodeString(onionService) 197 | if err != nil { 198 | log.Printf("Failed to decode %s because: %s\n", onionService, err) 199 | continue 200 | } 201 | 202 | for HSDirId, timePeriods := range HSDirs { 203 | 204 | // Iterate over time-period values when HSDir was online. 205 | for i := timePeriods[Start]; i <= timePeriods[End]; i++ { 206 | 207 | timePeriod[2] = uint8(i >> 8) 208 | timePeriod[3] = uint8(i % 256) 209 | 210 | for _, replica := range Replicas { 211 | 212 | // secret-id-part = H(time-period | descriptor-cookie | replica) 213 | // Descriptor cookies are not used in practice, so we only hash 214 | // time-period and replica. 215 | secretIdPart := sha1.Sum(append(timePeriod[:], replica)) 216 | descriptorIdRaw := sha1.Sum(append(permanentId, secretIdPart[:]...)) 217 | descriptorId = hex.EncodeToString(descriptorIdRaw[:]) 218 | 219 | if isNastyHSDir(HSDirId, descriptorId, onionService, timePeriod) { 220 | nastyHSDirs = append(nastyHSDirs, HSDirId) 221 | } 222 | } 223 | } 224 | } 225 | } 226 | 227 | log.Printf("%d out of %d HSes might have been attacked.\n", 228 | len(AttackedHSes), len(HSs)) 229 | 230 | return nastyHSDirs 231 | } 232 | 233 | func main() { 234 | 235 | var HSDirs map[string][2]int 236 | var start time.Time 237 | var end time.Time 238 | var err error 239 | var DefaultEndDate string = time.Now().Format("2006-01-02") 240 | 241 | HSDirsFile := flag.String("hsdirs", "", "File containing malicious hidden service directories, one per line.") 242 | HSDir := flag.String("hsdir", "", "The fingerprint of a single hidden service directory.") 243 | HSsFile := flag.String("hss", "", "File containing hidden services, one per line.") 244 | startDate := flag.String("start", DefaultStartDate, "The date the HSDir was first online in YYYY-MM-DD format. The default is 2005-01-01.") 245 | endDate := flag.String("end", DefaultEndDate, "The date the HSDir was last online in YYYY-MM-DD format. The default is today.") 246 | flag.Parse() 247 | 248 | if (*startDate != DefaultStartDate || *endDate != DefaultEndDate) && *HSDir == "" { 249 | log.Fatal("-start and -end only work in conjunction with -hsdir.") 250 | } 251 | 252 | if *HSDirsFile != "" { 253 | HSDirs = parseHSDirs(*HSDirsFile) 254 | } 255 | 256 | if *HSDir != "" { 257 | start, err = time.Parse("2006-01-02", *startDate) 258 | if err != nil { 259 | log.Fatalf("Failed to parse date when %s", err) 260 | } 261 | end, err = time.Parse("2006-01-02", *endDate) 262 | if err != nil { 263 | log.Fatalf("Failed to parse date when %s", err) 264 | } 265 | log.Printf("Using start date %s and end date %s.", start, end) 266 | 267 | // The map might already be initialised if -hsdirs was given. 268 | if HSDirs == nil { 269 | HSDirs = make(map[string][2]int) 270 | } 271 | // says: 272 | // time-period = (current-time + permanent-id-byte * 86400 / 256) / 86400 273 | HSDirs[*HSDir] = [2]int{int(start.Unix() / (24 * 60 * 60)), int(end.Unix()/(24*60*60) + 1)} 274 | } 275 | 276 | if len(HSDirs) == 0 { 277 | log.Fatal("No HSDirs given. Use either -hsdirs or -hsdir.") 278 | } 279 | 280 | iterateHSs(HSDirs, parseHSs(*HSsFile)) 281 | } 282 | -------------------------------------------------------------------------------- /code/itos/itos_test.go: -------------------------------------------------------------------------------- 1 | // Copyright 2017 Philipp Winter 2 | // 3 | // itos is free software: you can redistribute it and/or modify it under the 4 | // terms of the GNU General Public License as published by the Free Software 5 | // Foundation, either version 3 of the License, or (at your option) any later 6 | // version. 7 | // 8 | // itos is distributed in the hope that it will be useful, but WITHOUT ANY 9 | // WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS 10 | // FOR A PARTICULAR PURPOSE. See the GNU General Public License for more 11 | // details. 12 | // 13 | // You should have received a copy of the GNU General Public License along with 14 | // itos. If not, see . 15 | package main 16 | 17 | import ( 18 | "testing" 19 | ) 20 | 21 | func TestDescriptorDerivation(t *testing.T) { 22 | 23 | // Six HSDirs. Four are attacking the onion service, according to our 24 | // threshold. 25 | HSDirs := map[string][2]int{ 26 | // Descriptor ID: 31F1E5E501608D144A48EA5F49079E8A61FC3E18 27 | "31F1E5F9EDD602517A8BDD24032529F0DE431AAF": [2]int{17239, 17239}, 28 | "31F1E5F22F034B5F682EDE472CA6E3088DA27E5D": [2]int{17239, 17239}, 29 | "31F1A5FF4887230B0767F54BA08A450B68D777F2": [2]int{17239, 17239}, 30 | 31 | // Descriptor ID: 9AF82226CFB777531403F5A3D9BFF8751ED04FE7 32 | "9AF8225B3B8A9B82FA7DC1C6B34471D792F37818": [2]int{17239, 17239}, 33 | "9AF8227A68FC036B96A253B8A9599EE611490164": [2]int{17239, 17239}, 34 | "9AF812DF59D916E990CA52F233087499CAEAA038": [2]int{17239, 17239}, 35 | } 36 | HSs := []string{"AOPXFDVTE2QFATD2"} 37 | 38 | nastyHSDirs := iterateHSs(HSDirs, HSs) 39 | if len(nastyHSDirs) != (len(HSDirs) - 2) { 40 | t.Errorf("Incorrect number of attacking HSDirs (%d instead of %d).", 41 | len(nastyHSDirs), len(HSDirs)) 42 | } 43 | } 44 | -------------------------------------------------------------------------------- /code/vulnerable_key_data_to_csv.py: -------------------------------------------------------------------------------- 1 | import csv 2 | import pickle 3 | 4 | 5 | rsa_key_data = pickle.load(open('All_TOR_RSA_Key_Data.pck', 'rb')) 6 | all_hex_to_b64 = pickle.load(open('All-Hex-To-RSA.pck', 'rb')) 7 | 8 | vulnerable_moduli = open('vulnerable_moduli', 'r') 9 | 10 | header_row = [ 11 | 'VulnerableKey_b64', 'Modulus_Hex', 'KeyType', 'Nickname', 'Fingerprint', 12 | 'DatePub', 'ip4Address', 'Port', 'TorVersion', 'OS', 'Contact', 13 | 'AvgBandwith', 'Extra', 'Exponent' 14 | ] 15 | 16 | def get_row_from_key_data(key_data): 17 | """Get the CSV row corresponding to a given key data.""" 18 | if 'platform' in key_data: 19 | platform = key_data['platform'].split(' on ') 20 | tor_ver = platform[0] 21 | os = platform[1] 22 | else: 23 | tor_ver = None 24 | os = None 25 | 26 | return [ 27 | b64key, 28 | hex.replace('\n', ''), 29 | key_data.get('key_type'), 30 | key_data.get('nickname'), 31 | key_data.get('fingerprint'), 32 | key_data.get('date') and key_data['date'].strftime('%Y%m%d'), 33 | key_data.get('ip4_address'), 34 | key_data.get('port'), 35 | tor_ver, 36 | os, 37 | key_data.get('contact'), 38 | key_data.get('bandwidth'), 39 | key_data.get('extra'), 40 | exp 41 | ] 42 | 43 | # Write keys that have common GCDs. 44 | csv_writer = csv.writer(open('all_vulnerable_key_data.csv', 'wb')) 45 | csv_writer.writerow(header_row) 46 | for hex in vulnerable_moduli: 47 | rsa_key_list = all_hex_to_b64[hex.replace('\n', '')] 48 | 49 | key_dict = rsa_key_list[0] 50 | b64key = key_dict['rsa_pub_key'].replace('\n', '') 51 | exp = key_dict['exponent'] 52 | key_data = rsa_key_data[b64key.replace('\n', '')] 53 | 54 | csv_writer.writerow(get_row_from_key_data(key_data)) 55 | 56 | # Write keys that have repeated moduli. 57 | csv_writer = csv.writer(open('all_repeated_moduli_data.csv', 'wb')) 58 | csv_writer.writerow(header_row) 59 | for hex in all_hex_to_b64: 60 | rsa_key_list = all_hex_to_b64[hex.replace('\n', '')] 61 | if len(rsa_key_list) <= 1: 62 | continue 63 | 64 | for key_dict in rsa_key_list: 65 | b64key = key_dict['rsa_pub_key'].replace('\n', '') 66 | exp = key_dict['exponent'] 67 | key_data = rsa_key_data[b64key.replace('\n', '')] 68 | 69 | csv_writer.writerow(get_row_from_key_data(key_data)) 70 | 71 | -------------------------------------------------------------------------------- /paper/Makefile: -------------------------------------------------------------------------------- 1 | TARGET=main 2 | all: pdf 3 | 4 | pdf: 5 | GS_OPTIONS=-dPDFSETTINGS=/prepress rubber -f --pdf -Wrefs -Wmisc $(TARGET) 6 | 7 | clean: 8 | @rubber --clean --pdf $(TARGET) 9 | 10 | ps: pdf 11 | GS_OPTIONS=-dPDFSETTINGS=/prepress pdftops -level1 $(TARGET).pdf 12 | -------------------------------------------------------------------------------- /paper/abstract.tex: -------------------------------------------------------------------------------- 1 | \begin{abstract} 2 | In its more than ten years of existence, the Tor network has seen hundreds of 3 | thousands of relays come and go. Each relay maintains several RSA keys, 4 | amounting to millions of keys, all archived by The Tor Project. 5 | % 6 | In this paper, we analyze 3.7 million RSA public keys of Tor relays. We \first 7 | check if any relays share prime factors or moduli, \second identify relays that 8 | use non-standard exponents, \third characterize malicious relays that we 9 | discovered in the first two steps, and \fourth develop a tool that can determine 10 | what onion services fell prey to said malicious relays. 11 | % 12 | Our experiments revealed that ten relays shared moduli and 3,557 13 | relays---almost all part of a research project---shared prime factors, allowing 14 | adversaries to reconstruct private keys. We further discovered 122 relays that 15 | used non-standard RSA exponents, presumably in an attempt to attack onion 16 | services. By simulating how onion services are positioned in Tor's distributed 17 | hash table, we identified four onion services that were targeted by these 18 | malicious relays. 19 | % 20 | Our work provides both The Tor Project and onion service operators with tools to 21 | identify misconfigured and malicious Tor relays to stop attacks before they 22 | pose a threat to Tor users. 23 | 24 | \keywords{Tor, RSA, cryptography, factorization, onion service} 25 | \end{abstract} 26 | -------------------------------------------------------------------------------- /paper/acknowledgements.tex: -------------------------------------------------------------------------------- 1 | \section*{Acknowledgements} 2 | We want to thank Nadia Heninger and Josh Fried for augmenting their database 3 | with our moduli and attempting to find factors in them. We also want to 4 | thank Ralf-Philipp Weinmann, Ivan Pustogarov, Alex Biryukov from the Trawling 5 | research team and Donncha O'Cearbhaill from The Tor Project for providing us 6 | with additional information that helped us in our analysis of the weak keys. 7 | Finally, we want to thank Edward W. Felten for providing valuable feedback on 8 | an earlier version of our paper. This research was supported by the Center for 9 | Information Technology Policy at Princeton University and the National Science 10 | Foundation Awards CNS-1540066, CNS-1602399, CNS-1111539, CNS-1314637, 11 | CNS-1520552, and CNS-1640548. 12 | -------------------------------------------------------------------------------- /paper/appendix.tex: -------------------------------------------------------------------------------- 1 | \appendix 2 | 3 | \section{Potentially targeted onion services} 4 | 5 | \begin{table*} 6 | 7 | \caption{The details of the attacks on four onion services. The second 8 | column shows the fingerprints of the HSDirs that were participating in 9 | the attack. The third column shows the affected onion service 10 | descriptors, followed by the date of the attack in the last column.} 11 | \label{tab:collisions} 12 | 13 | \centering 14 | \scriptsize 15 | \begin{tabular}{l l l l} 16 | \toprule 17 | Onion service & Truncated HSDir fingerprint & Truncated onion service descriptor & Date \\ 18 | \midrule 19 | \texttt{22u75kqyl666joi2} & \hlfpr{325CAC0}{B7FA8CD77E39D} & \hlfpr{325CAC0}{8B0A3180B590E} & 2015-08-14 \\ 20 | & \hlfpr{325CAC0}{AB1AAD27493B9} & \hlfpr{325CAC0}{8B0A3180B590E} & 2015-08-14 \\ 21 | & \hlfpr{325CAC0}{A43B2121B81CD} & \hlfpr{325CAC0}{8B0A3180B590E} & 2015-08-14 \\ 22 | & \hlfpr{FA25674}{1ED22FD96AF5A} & \hlfpr{FA25674}{0740356704AB8} & 2015-08-14 \\ 23 | & \hlfpr{FA25674}{3ACFCA9B7C85D} & \hlfpr{FA25674}{0740356704AB8} & 2015-08-14 \\ 24 | & \hlfpr{E5E77832}{6AF0FF0A634A} & \hlfpr{E5E77832}{45096FB554A1} & 2015-08-15 \\ 25 | & \hlfpr{A5C59B3}{D0FFBDE88405E} & \hlfpr{A5C59B3}{CD34802FC4AC3} & 2015-08-15 \\ 26 | & \hlfpr{A5C59B3}{FCCD2FA8FAD42} & \hlfpr{A5C59B3}{CD34802FC4AC3} & 2015-08-15 \\ 27 | & \hlfpr{A5C59B3}{FD5625A0D85D1} & \hlfpr{A5C59B3}{CD34802FC4AC3} & 2015-08-15 \\ 28 | \midrule 29 | \texttt{n3q7l52nfpm77vnf} & \hlfpr{A0E83AA1}{91220B240EC0} & \hlfpr{A0E83AA1}{15098CA7FE9B} & 2016-11-27 \\ 30 | & \hlfpr{A0E83AA}{28382135DC839} & \hlfpr{A0E83AA}{115098CA7FE9B} & 2016-11-27 \\ 31 | & \hlfpr{EBF154D}{A21B49101ED5B} & \hlfpr{EBF154D}{809425D3E923E} & 2016-11-28 \\ 32 | & \hlfpr{EBF154D8}{BB6EECCC2921} & \hlfpr{EBF154D8}{09425D3E923E} & 2016-11-28 \\ 33 | & \hlfpr{EBF154D}{9E2B10A2420E0} & \hlfpr{EBF154D}{809425D3E923E} & 2016-11-28 \\ 34 | & \hlfpr{6761D2B}{E758FA0D76822} & \hlfpr{6761D2B}{CF40FF34274F3} & 2016-11-29 \\ 35 | & \hlfpr{59E415D}{78921BFF88168} & \hlfpr{59E415D}{5075157CAADB7} & 2016-11-29 \\ 36 | & \hlfpr{26597E6}{2875C498AC139} & \hlfpr{26597E6}{048BF7CC9D593} & 2016-11-30 \\ 37 | & \hlfpr{26597E6}{1DDFEE78F336D} & \hlfpr{26597E6}{048BF7CC9D593} & 2016-11-30 \\ 38 | & \hlfpr{7CDB224}{FE64F2A50CC50} & \hlfpr{7CDB224}{DC51432C037C5} & 2016-11-30 \\ 39 | & \hlfpr{2D148D3}{EBF9D2B9D8CCB} & \hlfpr{2D148D3}{CB6C5FC4DCA14} & 2016-12-01 \\ 40 | & \hlfpr{2E25D84}{69331FEAE933D} & \hlfpr{2E25D84}{2BF5DDA936BA2} & 2016-12-05 \\ 41 | & \hlfpr{2E25D84}{7E579AED1B0EC} & \hlfpr{2E25D84}{2BF5DDA936BA2} & 2016-12-05 \\ 42 | & \hlfpr{2E25D84}{54C96E20CF153} & \hlfpr{2E25D84}{2BF5DDA936BA2} & 2016-12-05 \\ 43 | & \hlfpr{2E25D84}{6564DCBE43CD2} & \hlfpr{2E25D84}{2BF5DDA936BA2} & 2016-12-05 \\ 44 | & \hlfpr{2E25D84}{47518DA93B4FF} & \hlfpr{2E25D84}{2BF5DDA936BA2} & 2016-12-05 \\ 45 | & \hlfpr{264EA12}{B47CBCC8043C5} & \hlfpr{264EA12}{410F7D9CD6E54} & 2016-12-05 \\ 46 | & \hlfpr{264EA12}{84855A596D5D6} & \hlfpr{264EA12}{410F7D9CD6E54} & 2016-12-05 \\ 47 | & \hlfpr{264EA12}{B4C46672E002C} & \hlfpr{264EA12}{410F7D9CD6E54} & 2016-12-05 \\ 48 | \midrule 49 | \texttt{silkroadvb5piz3r} & \hlfpr{BC89A}{92F53581C4F6169} & \hlfpr{BC89A}{889D3DF7F0027A5} & 2013-05-21 \\ 50 | & \hlfpr{712CA}{45AF4055E7AC69A} & \hlfpr{712CA}{3DEF4EB21C76A95} & 2013-05-22 \\ 51 | & \hlfpr{DE1529}{9D7EE5882F0BEF} & \hlfpr{DE1529}{316F5172B35B8E} & 2013-05-23 \\ 52 | & \hlfpr{FF0BF}{54FBEEE7A003CE6} & \hlfpr{FF0BF}{49076AA63C97FA2} & 2013-05-24 \\ 53 | & \hlfpr{E9F25}{C4899F9DC81E48E} & \hlfpr{E9F25}{BBA0D4501FAE18B} & 2013-05-28 \\ 54 | & \hlfpr{B81B43}{C015DE42D05208} & \hlfpr{B81B43}{637F22592ECC80} & 2013-05-29 \\ 55 | & \hlfpr{59529}{817C6E797D78311} & \hlfpr{59529}{79BD9FEECE847E7} & 2013-05-31 \\ 56 | & \hlfpr{BCB332}{864640653892D4} & \hlfpr{BCB332}{36E0AD461DF585} & 2013-06-02 \\ 57 | & \hlfpr{51FC17}{8DFF3D0B869760} & \hlfpr{51FC17}{2F0062B623A39D} & 2013-06-03 \\ 58 | \midrule 59 | \texttt{thehub7gqe43miyc} & \hlfpr{F6961286}{D361F825A9AD} & \hlfpr{F6961286}{C2FEEA8DEDEB} & 2015-08-22 \\ 60 | & \hlfpr{F6961286C}{453F6A6381D} & \hlfpr{F6961286C}{2FEEA8DEDEB} & 2015-08-22 \\ 61 | & \hlfpr{F6961286}{D826D7D1C0F9} & \hlfpr{F6961286}{C2FEEA8DEDEB} & 2015-08-22 \\ 62 | & \hlfpr{816FEE1}{6200BE1719D00} & \hlfpr{816FEE1}{5D26F41A72039} & 2015-08-22 \\ 63 | \bottomrule 64 | \end{tabular} 65 | \end{table*} 66 | -------------------------------------------------------------------------------- /paper/background.tex: -------------------------------------------------------------------------------- 1 | \section{Background} 2 | \label{sec:background} 3 | We now provide brief background on the RSA cryptosystem, how the Tor 4 | network employs RSA, and how onion services are implemented in the Tor network. 5 | 6 | \subsection{The RSA cryptosystem} 7 | The RSA public key cryptosystem uses key pairs consisting of a public encryption 8 | key and a privately held decryption key \cite{Rivest1978a}. The encryption key, 9 | or ``RSA public key,'' is comprised of a pair of positive integers: an exponent 10 | $e$ and a modulus $N$. The modulus $N$ is the product of two large, random prime 11 | numbers $p$ and $q$. The corresponding decryption key, or ``RSA private key,'' 12 | is comprised of the positive integer pair $d$ and $N$, where $N = pq$ and $d = 13 | e^{-1}$ mod $(p - 1)(q - 1)$. The decryption exponent $d$ is efficient to 14 | compute if $e$ and the factorization of $N$ are known. 15 | 16 | The security of RSA rests upon the difficulty of factorizing $N$ into its prime 17 | factors $p$ and $q$. While factorizing $N$ is impractical given sufficiently 18 | large prime factors, the greatest common divisor (GCD) of \emph{two moduli} can 19 | be computed in mere microseconds. Consider two distinct RSA moduli $N_1 = pq_1$ 20 | and $N_2 = pq_2$ that share the prime factor $p$. An attacker could quickly and 21 | easily compute the GCD of $N_1$ and $N_2$, which will be $p$, and then divide the 22 | moduli by $p$ to determine $q_1$ and $q_2$, thus compromising the private key of 23 | both key pairs. Therefore, it is crucial that both $p$ and $q$ are determined 24 | using a strong random number generator with a unique seed. 25 | 26 | Even though the naive GCD algorithm is very efficient, our dataset consists of 27 | more than 3.7 million keys and naively computing the GCD of every pair would 28 | take more than three years of computation (assuming 15 $\mu$s per pair). 29 | Instead, we use the fast pairwise GCD algorithm by Bernstein~\cite{Bernstein04} 30 | which can perform the computation at hand in just a few minutes. 31 | 32 | \subsection{The Tor network} 33 | \label{sec:tor-network} 34 | The Tor network is among the most popular tools for digital privacy and 35 | anonymity. As of December 2017, the Tor network consists of around 7,000 36 | volunteer-run relays~\cite{tormetrics}. Each hour, information about all 37 | relays\footnote{This information includes IP addresses, ports, version numbers, 38 | and cryptographic information, just to name a few.} is summarized in the 39 | \emph{network consensus}, which is used by clients to bootstrap a connection to 40 | the Tor network. The network consensus is produced by eight 41 | geographically-distributed \emph{directory authorities}, machines run by 42 | individuals trusted by The Tor Project. For each relay in the consensus, there 43 | is a pointer to its \emph{descriptor}, which contains additional, 44 | relay-specific information such as cryptographic keys. 45 | 46 | Each of the $\sim$7,000 relays maintains RSA, Curve25519, and Ed25519 key pairs 47 | to authenticate and protect client traffic~\cite[\S~1.1]{torspec}. In this work, 48 | we analyze the RSA keys. We leave the analysis of the other key types for 49 | future work. Each Tor relay has the following three 1024-bit RSA keys: 50 | 51 | \begin{figure}[t] 52 | \centering 53 | % Change arrow head globally. 54 | \tikzset{>=latex} 55 | \begin{tikzpicture} 56 | 57 | \node[circle,draw,minimum size=1cm] (R1) at (0, 0) {$R_n$}; 58 | \node[circle,draw,minimum size=1cm] (R2) at (5, 0) {$R_{n+1}$}; 59 | 60 | \draw[<->] (R1.east) -- node [midway, fill=white] (line) {\phantom{TLS layer}} (R2.west); 61 | 62 | \node[align=center] at (line) {{\color{gray} Application data}\\1--3 onion 63 | layers\\TLS layer\\{\color{gray}TCP}\\{\color{gray} IP}}; 64 | 65 | \end{tikzpicture} 66 | \caption{The protocol stack between two Tor relays $R_n$ and $R_n+1$. The 67 | lowest encryption layer is a TLS connection that contains one (between the 68 | middle and exit relay) to three (between the client and guard relay) onion 69 | layers. The onion layers protect the application data that the client is 70 | sending.} \label{fig:protostack} 71 | \end{figure} 72 | 73 | \begin{description} 74 | \item[Identity key] Relays have a long-term identity key that they use only 75 | to sign documents and certificates. Relays are frequently referred to 76 | by their fingerprints, which is a hash over their identity key. The 77 | compromise of an identity key would allow an attacker to impersonate a 78 | relay by publishing spoofed descriptors signed by the compromised 79 | identity key. 80 | 81 | \item[Onion key] Relays use medium-term onion keys to decrypt cells when 82 | circuits are created. The onion key is only used in the Tor 83 | Authentication Protocol that is now superseded by the ntor 84 | handshake~\cite{Goldberg2013a}. A compromised onion key allows the 85 | attacker to read the content of cells until the key pair rotates, which 86 | happens after 28 days~\cite[\S~3.4.1]{dir-spec}. 87 | However, the onion key layer is protected by a TLS layer (see 88 | Figure~\ref{fig:protostack}) that an attacker may have to find a way 89 | around. 90 | 91 | \item[Connection key] The short-term connection keys protect the connection 92 | between relays using TLS and are rotated at least once a 93 | day~\cite[\S~1.1]{torspec}. The TLS connection provides defense in 94 | depth as shown in Figure~\ref{fig:protostack}. If compromised, an 95 | attacker is able to see the encrypted cells that are exchanged between 96 | Tor relays. 97 | \end{description} 98 | 99 | In our work we consider the identity keys and onion keys that each relay has 100 | because the Tor Project has been archiving the public part of the identity and 101 | onion keys for more than ten years, allowing us to draw on a rich 102 | dataset~\cite{collector}. The Tor Project does not archive the connection keys 103 | because they have short-term use and are not found in the network consensus or 104 | relay descriptors. 105 | 106 | \subsection{Onion services} 107 | In addition to client anonymity, the Tor network allows operators to set up 108 | anonymous servers, typically called ``onion services.''\footnote{The term ``hidden 109 | services'' was used in the past but was discontinued, in part because onion 110 | services provide more than just ``hiding'' a web site.} The so-called ``hidden 111 | service directories,'' or ``HSDirs,'' are a subset of all Tor relays and 112 | comprise a distributed hash table (DHT) that stores the information necessary 113 | for a client to connect to an onion service. These HSDirs are a particularly 114 | attractive target to adversaries because they get to learn about onion services 115 | that are set up in the Tor network. An onion service's position in the DHT is 116 | governed by the following equations: 117 | 118 | \begin{equation} 119 | \begin{split} 120 | \textit{secret-id-part} = \textit{SHA-1}(& \textit{time-period} \mid \\ 121 | & \textit{descriptor-cookie} \mid \\ 122 | & \textit{replica}) \\ 123 | \textit{descriptor-id} = \textit{SHA-1}(& \textit{permanent-id} \mid \\ 124 | & \textit{secret-id-part}) 125 | \end{split} 126 | \end{equation} 127 | 128 | \begin{figure}[t] 129 | \centering 130 | % Change arrow head globally. 131 | \tikzset{>=latex} 132 | \begin{tikzpicture} 133 | 134 | % Day t+1 135 | \node at (0.2,0.4) {\textbf{Day \emph{t}+1:}}; 136 | 137 | \draw[,->] (0,0) node[anchor=north] {{\footnotesize \texttt{0x00..00}}} -- 138 | (6.8,0) node[anchor=north] {{\footnotesize \texttt{0xff..ff}}}; 139 | 140 | \draw[fill=white] (0.1,0) circle (1mm); 141 | \draw[fill=white] (0.6,0) circle (1mm); 142 | \draw[fill=white] (1.0,0) circle (1mm); 143 | \draw[fill=white] (1.5,0) circle (1mm); 144 | \draw[fill=white] (1.7,0) circle (1mm); 145 | 146 | \draw[line width=0.7mm, red] (2,-0.1) -- (2,0.1); 147 | \draw[,->] (2,0) -- (2,-0.5) node[anchor=north] {Descriptor ID}; 148 | 149 | \draw[fill=cyan] (2.3,0) circle (1mm); 150 | \draw[fill=cyan] (2.7,0) circle (1mm); 151 | \draw[fill=cyan] (3.0,0) circle (1mm); 152 | \draw[,->] (2.3,0) -- (2.6,0.5); 153 | \draw[,->] (2.7,0) -- (2.7,0.5) node[anchor=south] {Replica \#1}; 154 | \draw[,->] (3.0,0) -- (2.8,0.5); 155 | 156 | \draw[fill=white] (3.3,0) circle (1mm); 157 | \draw[fill=white] (3.6,0) circle (1mm); 158 | \draw[fill=white] (4.0,0) circle (1mm); 159 | 160 | \draw[fill=orange] (4.2,0) circle (1mm); 161 | \draw[fill=orange] (4.6,0) circle (1mm); 162 | \draw[fill=orange] (5.0,0) circle (1mm); 163 | \draw[,->] (4.2,0) -- (4.5,0.5); 164 | \draw[,->] (4.6,0) -- (4.6,0.5) node[anchor=south] {Replica \#2}; 165 | \draw[,->] (5.0,0) -- (4.7,0.5); 166 | 167 | \draw[fill=white] (5.3,0) circle (1mm); 168 | \draw[fill=white] (5.8,0) circle (1mm); 169 | \draw[fill=white] (6.2,0) circle (1mm); 170 | \draw[fill=white] (6.5,0) circle (1mm); 171 | 172 | \draw[dotted] (0,1.0) -- (6.8,1.0); 173 | 174 | % Day t 175 | \node at (0.2,2.4) {\textbf{Day \emph{t}:\phantom{+1}}}; 176 | 177 | \draw[,->] (0,2) node[anchor=north] {{\footnotesize \texttt{0x00..00}}} -- 178 | (6.8,2) node[anchor=north] {{\footnotesize \texttt{0xff..ff}}}; 179 | 180 | \draw[fill=white] (0.1,2) circle (1mm); 181 | \draw[fill=white] (0.6,2) circle (1mm); 182 | 183 | \draw[fill=orange] (1.0,2) circle (1mm); 184 | \draw[fill=orange] (1.5,2) circle (1mm); 185 | \draw[fill=orange] (1.7,2) circle (1mm); 186 | \draw[,->] (1.0,2) -- (1.4,2.5); 187 | \draw[,->] (1.5,2) -- (1.5,2.5) node[anchor=south] {Replica \#2}; 188 | \draw[,->] (1.7,2) -- (1.6,2.5); 189 | 190 | \draw[fill=white] (2.3,2) circle (1mm); 191 | \draw[fill=white] (2.7,2) circle (1mm); 192 | \draw[fill=white] (3.0,2) circle (1mm); 193 | \draw[fill=white] (3.3,2) circle (1mm); 194 | \draw[fill=white] (3.6,2) circle (1mm); 195 | \draw[fill=white] (4.0,2) circle (1mm); 196 | \draw[fill=white] (4.2,2) circle (1mm); 197 | \draw[fill=white] (4.6,2) circle (1mm); 198 | \draw[fill=white] (5.0,2) circle (1mm); 199 | 200 | \draw[line width=0.7mm, red] (5.15,1.9) -- (5.15,2.1); 201 | \draw[,->] (5.15,2) -- (5.15,1.5) node[anchor=north] {Descriptor ID}; 202 | 203 | \draw[fill=cyan] (5.3,2) circle (1mm); 204 | \draw[fill=cyan] (5.8,2) circle (1mm); 205 | \draw[fill=cyan] (6.2,2) circle (1mm); 206 | \draw[,->] (5.3,2) -- (5.7,2.5); 207 | \draw[,->] (5.8,2) -- (5.8,2.5) node[anchor=south] {Replica \#1}; 208 | \draw[,->] (6.2,2) -- (5.9,2.5); 209 | 210 | \draw[fill=white] (6.5,2) circle (1mm); 211 | 212 | \end{tikzpicture} 213 | \caption{Each day, an onion service places its descriptor ID at a pseudorandom 214 | location in Tor's ``hash ring,'' which consists of all HSDir relays 215 | (illustrated as circles).} 216 | \label{fig:hash-ring} 217 | \end{figure} 218 | 219 | \textit{Secret-id-part} depends on three variables: \textit{time-period} 220 | represents the number of days since the Unix epoch; \textit{descriptor-cookie} 221 | is typically unused and hence empty; and \textit{replica} is set to both the 222 | values 0 and 1, resulting in two hashes for \textit{secret-id-part}. The 223 | concatenation of both \textit{permanent-id} (the onion service's hashed public 224 | key) and \textit{secret-id-part} is hashed, resulting in \textit{descriptor-id}, 225 | which determines the position in the DHT. When arranging all HSDirs by their 226 | fingerprint in ascending order, the three immediate HSDir neighbors in the positive 227 | direction constitute the first replica while the second replica is at another, 228 | pseudorandom location, as shown in Figure~\ref{fig:hash-ring}. The onion 229 | service's descriptor ID and hence, its two replicas, changes every day when 230 | \textit{time-period} increments. 231 | -------------------------------------------------------------------------------- /paper/conclusion.tex: -------------------------------------------------------------------------------- 1 | \section{Conclusion} 2 | \label{sec:conclusion} 3 | 4 | Inspired by recent research that studied weak keys in deployed systems, we set 5 | out to investigate if the Tor network suffers from similar issues. To that 6 | end, we drew on a public archive containing cryptographic keys of Tor relays 7 | dating back to 2005, which we subsequently analyzed for weak RSA keys. We 8 | discovered that \first ten relays shared an RSA modulus, \second 3,557 relays 9 | shared prime factors, and \third 122 relays used non-standard RSA exponents. 10 | 11 | Having uncovered these anomalies, we then proceeded to characterize the 12 | affected relays, tracing back the issues to mostly harmless experiments run by 13 | academic researchers and hobbyists, but also to attackers that targeted Tor's 14 | distributed hash table which powers onion services. To learn more, we 15 | implemented a tool that can determine what onion services were attacked by a 16 | given set of malicious Tor relays, revealing four onion services that fell prey 17 | to these attacks. 18 | 19 | The practical value of our work is twofold. First, our uncovering and 20 | characterizing of Tor relays with anomalous keys provides an anatomy of 21 | real-world attacks that The Tor Project can draw upon to improve its monitoring 22 | infrastructure for malicious Tor relays. Second, our work provides The Tor 23 | Project with tools to verify the RSA keys of freshly set up relays, making the 24 | network safer for its users. In addition, onion service operators can use our 25 | code to monitor their services and get notified if Tor relays make an effort to 26 | deanonymize their onion service. We believe that this is particularly useful 27 | for sensitive deployments such as SecureDrop instances. 28 | -------------------------------------------------------------------------------- /paper/discussion.tex: -------------------------------------------------------------------------------- 1 | \section{Discussion} 2 | \label{sec:discussion} 3 | We now turn to the technical and ethical implications of our research, propose 4 | possible future work, and explain how the next generation of onion 5 | services will thwart DHT manipulation attacks. 6 | 7 | \subsection{Implications of anomalous Tor keys} 8 | \paragraph{Implications for the network} 9 | As touched on earlier in Section~\ref{sec:tor-network}, the main use of the 10 | identity key in Tor is to sign the relay's descriptor, which includes various 11 | information about the relay, \eg, its IP address and contact information. 12 | Relays publish their public identity keys in their descriptor. The network 13 | consensus acts as the public key infrastructure of Tor. Signed by the directory 14 | authorities whose public keys are hard-coded in Tor's source code, the network 15 | consensus points to the descriptors of each Tor relay that is currently online. 16 | If an attacker were to break the identity key of a relay (as we demonstrated), 17 | she could start signing descriptors in the relay's name and publishing them. The 18 | adversary could publish whatever information she wanted in the descriptor, \eg 19 | her own IP address, keys, \etc, in order to fool Tor clients. In other words, 20 | weak keys allow adversaries to obtain the affected relay's reputation which 21 | matters because Tor clients make routing decisions based on this reputation. 22 | 23 | The Tor protocol's use of forward secrecy mitigates the potential harm of weak 24 | keys. Recall that a relay's long-lived identity keys are only used to sign 25 | data, so forward secrecy does not apply here. Onion keys, however, are used for 26 | decryption and encryption and are rotated by default every 28 27 | days~\cite[\S~3.4.1]{dir-spec}. An attacker who manages to compromise a weak 28 | onion key is still faced with the underlying TLS layer, shown in 29 | Figure~\ref{fig:protostack}, which provides defense in depth. The Tor 30 | specification requires the keys for the TLS layer to be rotated at least once a 31 | day~\cite[\S~1.1]{torspec}, making it difficult to get any use out of 32 | compromised onion keys. 33 | 34 | \paragraph{Implications for Tor users} 35 | To understand how Tor users are affected by weak keys we need to distinguish 36 | between \emph{targeting} and \emph{hoovering} adversaries.\footnote{We here use 37 | Jaggard and Syverson's nomenclature of an adversary that either targets 38 | specific Tor users (targeting) or hoovers up all available data to 39 | deanonymize as many users as possible (hoovering)~\cite{Jaggard2017a}.} 40 | The goal of targeting adversaries is to focus an attack on a small number of 41 | users among the large set of all Tor users. Generally speaking, weak keys can 42 | be problematic in a targeted setting if they allow an attacker to gain access to 43 | a Tor relay she would otherwise be unable to control. This can be the case if 44 | the attacker learned the targeted user's guard relay, and the guard happens 45 | to have weak keys. However, judging by our experimental results, the 46 | probability of an attacker's knowing a targeted user's guard relay \emph{and} 47 | said guard relay's having vulnerable keys is very low. 48 | 49 | Hoovering adversaries are opportunistic by definition and seek to deanonymize as 50 | many Tor users as possible. Recall that Tor clients use a long-lived guard 51 | relay as their first hop and two randomly chosen relays for the next two 52 | hops.\footnote{We refer to these relays as randomly chosen for simplicity, but 53 | the path selection algorithm is more complicated.} A single compromised relay 54 | is not necessarily harmful to users but weak keys can be a problem if a user 55 | happens to have a guard relay with weak keys \emph{and} selects an exit relay 56 | that also has weak keys, allowing the hoovering adversary to deanonymize the 57 | circuit. Again, considering the low prevalence of weak keys and the ease with 58 | which The Tor Project could identify and block relays with weak keys, hoovering 59 | adversaries pose no significant threat. 60 | 61 | \subsection{Preventing non-standard exponents} 62 | Recall that the Tor reference implementation hard-codes its public RSA exponent 63 | to 65,537~\cite[\S~0.3]{torspec}. The Tor Project could prevent non-standard 64 | exponents by having the directory authorities reject relays whose descriptors 65 | have an RSA exponent other than 65,537, thus slowing down the search for 66 | fingerprint prefixes. Adversaries would then have to iterate over the primes 67 | $p$ or $q$ instead of the exponent, rendering the search computationally 68 | more expensive because of the cost of primality tests. Given that we discovered 69 | only 122 unusual exponents in over ten years of data, we believe that rejecting 70 | non-standard exponents is a viable defense in depth. 71 | 72 | \subsection{Analyzing onion service public keys} 73 | Future work should shed light on the public keys of onion services. Onion 74 | services have an incentive to modify their fingerprints to make them both 75 | recognizable and easier to remember. Facebook, for example, was lucky to 76 | obtain the easy-to-remember onion domain 77 | \url{facebookcorewwwi.onion}~\cite{facebook}. The tool Scallion assists onion 78 | service operators in creating such vanity domains~\cite{scallion}. The 79 | implications of vanity domains on usability and security are still poorly 80 | understood~\cite{vanity-domains}. Unlike the public keys of relays, onion 81 | service keys are not archived, so a study would have to begin with actively 82 | fetching onion service keys. 83 | 84 | \subsection{Investigating the vulnerability of Tor relays to attacks on Diffie-Hellman} 85 | Recent work has demonstrated how Diffie-Hellman key exchange is vulnerable to 86 | attack~\cite{Adrian2015a,Valenta2017a,Dorey2017a}. Because Tor uses 87 | Diffie-Hellman, we decided to investigate how it might be affected by those 88 | findings. The Tor specification states that the implementation uses the Second 89 | Oakley Group for Diffie-Hellman, where the prime number is 1024 bits 90 | long~\cite[\S~0.3]{torspec}. To gather evidence of this usage, we performed an 91 | nmap scan on Tor relays using the ssl-dh-params script~\cite{nmapdhscript}, 92 | which confirmed the Tor specification. The use of a 1024-bit prime is 93 | concerning because Adrian \ea~\cite{Adrian2015a} stated that ``1024-bit discrete 94 | log may be within reach for state-level actors,'' and thus, they suggest a move 95 | to 2048 bits. The authors also mention that developers should move away from 96 | using 1024-bit RSA, as well, which Tor uses. 97 | 98 | \subsection{\textit{In vivo} Tor research} 99 | Caution must be taken when conducting research using the live Tor network. 100 | Section~\ref{sec:shared-primes} showed how a small mistake in key generation led 101 | to many vulnerable Tor relays. To keep its users safe, The Tor Project has 102 | recently launched a research safety board whose aim is to assist researchers in 103 | safely conducting Tor measurement studies~\cite{safety-board}. This may entail 104 | running experiments in private Tor networks that are controlled by the 105 | researchers or using network simulators such as Shadow~\cite{Jansen2012a}. 106 | 107 | As for our own work, we were in close contact with Tor developers throughout our 108 | research effort and shared preliminary results as we progressed. Once we wrote 109 | up our findings in a technical report, we brought it to the broader Tor 110 | community's attention by sending an email to the tor-dev mailing 111 | list~\cite{Roberts2017a}. On top of that, we adopted open science practices and 112 | wrote both our code and paper in the open, allowing interested parties to follow 113 | our progress easily. 114 | 115 | \subsection{The effect of next-generation onion services} 116 | As of December 2017, The Tor Project is testing the implementation of 117 | next-generation onion services~\cite{prop224}. In addition to stronger 118 | cryptographic primitives, the design fixes the issue of predicting an onion 119 | service's location in the hash ring by incorporating a random element. This 120 | element is produced by having the directory authorities agree on a random number 121 | once a day~\cite{prop250}. The random number is embedded in the consensus 122 | document and used by clients to fetch an onion service's descriptor. Attackers 123 | will no longer be able to attack onion services by positioning HSDirs in the 124 | hash ring; while they have several hours to compute a key pair that positions 125 | their HSDirs next to the onion service's descriptor (which is entirely 126 | feasible), it takes at least 96 hours to get the HSDir flag from the directory 127 | authorities~\cite[\S~3.4.2]{dir-spec}, so attackers cannot get the flag in time. 128 | We expect this design change to disincentivize attackers from manipulating their 129 | keys to attack onion services. 130 | -------------------------------------------------------------------------------- /paper/introduction.tex: -------------------------------------------------------------------------------- 1 | \section{Introduction} 2 | Having seen hundreds of thousands of relays come and go over the last decade, 3 | the Tor network is the largest volunteer-run anonymity network. To implement 4 | onion routing, all the relays maintain several RSA key pairs, the most important 5 | of which are a medium-term key that rotates occasionally and a long-term key 6 | that ideally never changes. Most relays run The Tor Project's reference C 7 | implementation on dedicated Linux systems, but some run third-party 8 | implementations or operate on constrained systems such as Raspberry Pis which 9 | raises the question of whether these machines managed to generate safe keys upon 10 | bootstrapping. Past work has investigated the safety of keys in TLS and SSH 11 | servers~\cite{Heninger2012a}, in nation-wide databases~\cite{Bernstein2013a}, as 12 | well as in POP3S, IMAPS, and SMTPS servers~\cite{Hastings2016a}. In this work, 13 | we study the Tor network and pay particular attention to Tor-specific aspects 14 | such as onion services. 15 | 16 | Relays with weak cryptographic keys can pose a significant threat to Tor users. 17 | The exact impact depends on the type of key that is vulnerable. In the best 18 | case, an attacker only manages to compromise the TLS layer that protects Tor 19 | cells, which are also encrypted. In the worst case, an attacker compromises a 20 | relay's long-term ``identity key,'' allowing her to impersonate the relay. To 21 | protect Tor users, we need methods to find relays with vulnerable keys and 22 | remove them from the network before adversaries can exploit them. 23 | 24 | Drawing on a publicly-archived dataset of 3.7 million RSA public 25 | keys~\cite{collector}, we set out to analyze these keys for weaknesses and 26 | anomalies: we looked for shared prime factors, shared moduli, and non-standard 27 | RSA exponents. To our surprise, we found more than 3,000 keys with shared prime 28 | factors, most belonging to a 2013 research project~\cite{Biryukov2013a}. Ten 29 | relays in our dataset shared a modulus, suggesting manual interference with the 30 | key generation process. Finally, we discovered 122 relays whose RSA exponent 31 | differed from Tor's hard-coded exponent. Most of these relays were meant to 32 | manipulate Tor's distributed hash table (DHT) in an attempt to attack onion 33 | services as we discuss in Section~\ref{sec:targeted-onion-services}. To learn 34 | more, we implemented a tool---itos\footnote{The name is an acronym for 35 | ``identifying targeted onion services.''}---that simulates how onion services 36 | are placed on the DHT, revealing four onion services that were targeted by some 37 | of these malicious relays. Onion service operators can use our tool to monitor 38 | their services' security; \eg, a newspaper can make sure that its SecureDrop 39 | deployment---which uses onion services---is safe~\cite{securedrop}. 40 | 41 | The entities responsible for the incidents we uncovered are as diverse as the 42 | incidents themselves: researchers, developers, and actual adversaries were all 43 | involved in generating key anomalies. By looking for information that relays 44 | had in common, such as similar nicknames, IP address blocks, uptimes, and port 45 | numbers, we were able to group the relays we discovered into clusters that were 46 | likely operated by the same entities, shedding light on the anatomy of 47 | real-world attacks against Tor. 48 | 49 | We publish all our source code and data, allowing third parties such as The Tor 50 | Project to continuously check the keys of new relays and alert developers if 51 | any of these keys are vulnerable or non-standard.\footnote{Our project page is 52 | available online at \url{https://nymity.ch/anomalous-tor-keys/}.} Tor 53 | developers can then take early action and remove these relays from the network 54 | before adversaries get the chance to take advantage of them. In summary, we 55 | make the following three contributions: 56 | \begin{itemize} 57 | \item We analyze a dataset consisting of 3.7 million RSA public keys for 58 | weak and non-standard keys, revealing thousands of affected keys. 59 | 60 | \item We characterize the relays we discovered, show that many were 61 | likely operated by a single entity, and uncover four onion services that 62 | were likely targeted. 63 | 64 | \item Given a set of malicious Tor relays that served as ``hidden service 65 | directories,'' we develop and implement a method that can reveal what 66 | onion services these relays were targeting. 67 | \end{itemize} 68 | 69 | The rest of this paper details our project. In Section~\ref{sec:background}, we 70 | provide background information, followed by Section~\ref{sec:related} where we 71 | discuss related work. In Section~\ref{sec:method}, we describe our method, 72 | and Section~\ref{sec:results} presents our results. We discuss our work in 73 | Section~\ref{sec:discussion} and conclude in Section~\ref{sec:conclusion}. 74 | -------------------------------------------------------------------------------- /paper/main.tex: -------------------------------------------------------------------------------- 1 | \documentclass{llncs} 2 | 3 | \usepackage[utf8]{inputenc} 4 | \usepackage[scaled=0.8]{beramono} 5 | \usepackage[T1]{fontenc} 6 | \usepackage{booktabs} % For pretty tables. 7 | \usepackage{multirow} % Also for pretty tables. 8 | \usepackage[pagebackref=true]{hyperref} % For clickable links. 9 | \usepackage{makeidx} % allows for indexgeneration 10 | \usepackage{xcolor} % For colourful links. 11 | \usepackage{xspace} % For reasonable spacing in custom commands. 12 | \usepackage{wrapfig} % For floating figures. 13 | \usepackage{amsmath} 14 | \usepackage{tikz} 15 | \urlstyle{tt} 16 | 17 | % Better back references in the references. 18 | \renewcommand*{\backref}[1]{} 19 | \renewcommand*{\backrefalt}[4]{({% 20 | \ifcase #1 Not cited.% 21 | \or Cited on p.~#2.% 22 | \else Cited on pp.~#2.% 23 | \fi% 24 | })} 25 | 26 | \definecolor{highlight1}{rgb}{0.863,0.863,0.863} 27 | \definecolor{highlight2}{rgb}{0.734,1.000,0.898} 28 | \definecolor{highlight3}{rgb}{0.867,0.758,1.000} 29 | \definecolor{highlight4}{rgb}{1.000,0.977,0.734} 30 | \definecolor{highlight5}{rgb}{1.000,0.816,0.734} 31 | 32 | \definecolor{darkblue}{rgb}{0,0,0.4} 33 | \definecolor{lightgray}{rgb}{0.93,0.93,0.93} 34 | 35 | \hypersetup{ 36 | colorlinks=true, 37 | urlcolor=darkblue, 38 | linkcolor=darkblue, 39 | citecolor=darkblue, 40 | pdftitle={Anomalous keys in Tor relays}, 41 | pdfauthor={George Kadianakis, Claudia V. Roberts, Laura M. Roberts, and Philipp Winter}, 42 | pdfkeywords={Tor, RSA, onion service, cryptography, factorization}, 43 | pdfsubject={An analysis of archived RSA public keys of Tor relays}, 44 | } 45 | 46 | \newcommand{\xxx}[1]{\textcolor{red}{#1}} 47 | \newcommand{\fixme}[1]{\textcolor{red}{{\bf FIXME:} #1}\xspace} 48 | \newcommand{\ie}{{i.e.}\xspace} 49 | \newcommand{\eg}{{e.g.}\xspace} 50 | \newcommand{\ea}{{et al.}\xspace} 51 | \newcommand{\etc}{{etc.}\xspace} 52 | \newcommand{\first}{(\emph{i})\xspace} 53 | \newcommand{\second}{(\emph{ii})\xspace} 54 | \newcommand{\third}{(\emph{iii})\xspace} 55 | \newcommand{\fourth}{(\emph{iv})\xspace} 56 | \newcommand{\fifth}{(\emph{v})\xspace} 57 | \newcommand{\hlfpr}[2]{% 58 | \texttt{\setlength{\fboxsep}{0pt}% 59 | \colorbox{highlight1}{\strut #1}#2}} 60 | 61 | \setcounter{tocdepth}{3} 62 | 63 | \begin{document} 64 | 65 | \title{``Major key alert!''\\Anomalous keys in Tor relays} 66 | \titlerunning{Anomalous keys in Tor relays} 67 | 68 | \author{ 69 | George Kadianakis\inst{1}\thanks{All four authors contributed substantially 70 | and share first authorship. The names are ordered alphabetically.} \and 71 | Claudia V. Roberts\inst{2} \and 72 | Laura M. Roberts\inst{2} \and \\ 73 | Philipp Winter\inst{2} 74 | } 75 | 76 | \institute{ 77 | The Tor Project 78 | \and 79 | Princeton University 80 | } 81 | 82 | \authorrunning{Kadianakis et al.} % abbreviated author list (for running head) 83 | 84 | \pagestyle{headings} % switches on printing of running heads 85 | 86 | \maketitle 87 | 88 | \input{abstract} 89 | 90 | \input{introduction} 91 | 92 | \input{background} 93 | 94 | \input{related} 95 | 96 | \input{method} 97 | 98 | \input{results} 99 | 100 | \input{discussion} 101 | 102 | \input{conclusion} 103 | 104 | \input{acknowledgements} 105 | 106 | \bibliographystyle{splncs03} 107 | \bibliography{references.bib}{} 108 | 109 | \newpage 110 | 111 | \input{appendix} 112 | 113 | \end{document} 114 | -------------------------------------------------------------------------------- /paper/method.tex: -------------------------------------------------------------------------------- 1 | \section{Method} 2 | \label{sec:method} 3 | In this section, we discuss how we drew on a publicly-available dataset 4 | (Section~\ref{sec:data-collection}) and used Heninger and Halderman's 5 | fastgcd~\cite{fastgcd} tool to analyze the public keys that 6 | we extracted from this dataset (Section~\ref{sec:vulnerable-keys}). 7 | 8 | \subsection{Data collection} 9 | \label{sec:data-collection} 10 | The Tor Project archives data about Tor relays on its CollecTor 11 | platform~\cite{collector}, allowing researchers to learn what relays were online 12 | at any point in the past. Drawing on this data source, we compiled a set of RSA 13 | keys by downloading all server descriptors from December 2005 to December 2016 14 | and extracting the identity and onion keys with the Stem Python 15 | library~\cite{stem}. Table~\ref{tab:dataset} provides an overview of the 16 | resulting dataset---approximately 200 GB of unzipped data. Our 3.7 million 17 | public keys span eleven years and were created on one million IP addresses. 18 | 19 | Our dataset also contains the keys of Tor's directory authorities. The 20 | authorities' keys are particularly sensitive: If an attacker were to compromise 21 | more than half of these keys, she could create a malicious network 22 | consensus---which could consist of attacker-controlled relays only---that would 23 | then be used by Tor clients. Therefore these keys are paramount to the security 24 | of the Tor network. 25 | 26 | \begin{table}[t] 27 | \caption{An overview of our RSA public key dataset.} 28 | \label{tab:dataset} 29 | \centering 30 | \begin{tabular}{l r} 31 | \toprule 32 | 33 | First key published & 2005-12 \\ 34 | Last key published & 2016-12 \\ 35 | 36 | \midrule 37 | 38 | Number of relays (by IP address) & 1,083,805 \\ 39 | Number of onion keys & 3,174,859 \\ 40 | Number of identity keys & 588,945 \\ 41 | Total number of public keys & 3,763,804 \\ 42 | 43 | \bottomrule 44 | \end{tabular} 45 | \end{table} 46 | 47 | \subsection{Finding vulnerable keys} 48 | \label{sec:vulnerable-keys} 49 | To detect weak, potentially factorable keys in the Tor network, we used Heninger 50 | and Halderman's fastgcd~\cite{fastgcd} tool which takes as input a set 51 | of moduli from public keys and then computes the pair-wise greatest common 52 | divisor of these moduli. Fastgcd's C implementation is based on a 53 | quasilinear-time algorithm for factoring a set of integers into their co-primes. 54 | We used the PyCrypto library~\cite{pycrypto} to turn Tor's PKCS\#1-padded, 55 | PEM-encoded keys into fastgcd's expected format, which is hex-encoded 56 | moduli. Running fastgcd over our dataset took less than 20 minutes on 57 | a machine with dual, eight-core 2.8 GHz Intel Xeon E5 2680 v2 processors with 58 | 256 GB of RAM. 59 | 60 | Fastgcd benefits from having access to a pool of moduli that is as large as possible 61 | because it allows the algorithm to draw on a larger factor base to use on each 62 | key~\cite{Heninger2012a}. To that end, we reached out to Heninger's group at 63 | the University of Pennsylvania, and they graciously augmented their 129 million 64 | key dataset with our 3.6 million keys and subsequently searched for shared 65 | factors. The number of weak keys did not go up, but this experiment gave us 66 | more confidence that we had not missed weak keys. 67 | -------------------------------------------------------------------------------- /paper/references.bib: -------------------------------------------------------------------------------- 1 | @inproceedings{Jaggard2017a, 2 | author = {Aaron D. Jaggard and Paul Syverson}, 3 | title = {Oft Target}, 4 | booktitle = {HotPETs}, 5 | year = {2017}, 6 | url = {https://petsymposium.org/2017/papers/hotpets/oft-target-1707.pdf}, 7 | } 8 | 9 | @inproceedings{Jansen2012a, 10 | title = {{Shadow}: Running {Tor} in a Box for Accurate and Efficient Experimentation}, 11 | author = {Rob Jansen and Nicholas Hopper}, 12 | booktitle = {NDSS}, 13 | year = {2012}, 14 | publisher = {Internet Society}, 15 | url = {http://www.robgjansen.com/publications/shadow-ndss2012.pdf}, 16 | note = {(visited on 2017-05-09)}, 17 | } 18 | 19 | @misc{Dingledine2014a, 20 | author = {Roger Dingledine}, 21 | title = {{Tor} security advisory: ``relay early'' traffic confirmation attack}, 22 | month = jul, 23 | year = {2014}, 24 | url = {https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack/}, 25 | note = {(visited on 2017-05-09)}, 26 | } 27 | 28 | % url = {https://nymity.ch/anomalous-tor-keys/pdf/Goldberg2013a.pdf}, 29 | @article{Goldberg2013a, 30 | author = {Ian Goldberg and Douglas Stebila and Berkant Ustaoglu}, 31 | title = {Anonymity and one-way authentication in key exchange protocols}, 32 | journal = {Designs, Codes and Cryptography}, 33 | volume = {67}, 34 | number = {2}, 35 | year = {2013}, 36 | pages = {245--269}, 37 | note = {(visited on 2017-05-09)}, 38 | } 39 | 40 | % url = {https://nymity.ch/anomalous-tor-keys/pdf/Coppersmith1996a.pdf}, 41 | @inproceedings{Coppersmith1996a, 42 | author = {Don Coppersmith}, 43 | title = {Finding a Small Root of a Bivariate Integer Equation; Factoring with High Bits Known}, 44 | booktitle = {EUROCRYPT}, 45 | publisher = {Springer}, 46 | year = {1996}, 47 | pages = {178--189}, 48 | note = {(visited on 2017-05-09)}, 49 | } 50 | 51 | @article{Coppersmith1997a, 52 | author = {Don Coppersmith}, 53 | title = {Small Solutions to Polynomial Equations, and Low Exponent {RSA} Vulnerabilities}, 54 | journal = {Journal of Cryptology}, 55 | volume = {10}, 56 | number = {4}, 57 | year = {1997}, 58 | pages = {233--260}, 59 | url = {https://www.di.ens.fr/~fouque/ens-rennes/coppersmith.pdf}, 60 | note = {(visited on 2017-05-09)}, 61 | } 62 | 63 | @inproceedings{Biryukov2013a, 64 | author = {Alex Biryukov and Ivan Pustogarov and Ralf-Philipp Weinmann}, 65 | title = {Trawling for {Tor} Hidden Services: Detection, Measurement, Deanonymization}, 66 | booktitle = {Security and Privacy}, 67 | publisher = {IEEE}, 68 | year = {2013}, 69 | url = {http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf}, 70 | note = {(visited on 2017-05-09)}, 71 | } 72 | 73 | @inproceedings{Heninger2012a, 74 | author = {Nadia Heninger and Zakir Durumeric and Eric Wustrow and J. Alex Halderman}, 75 | title = {Mining Your {Ps} and {Qs}: Detection of Widespread Weak Keys in Network Devices}, 76 | booktitle = {USENIX Security}, 77 | publisher = {USENIX}, 78 | year = {2012}, 79 | url = {https://factorable.net/weakkeys12.extended.pdf}, 80 | note = {(visited on 2017-05-09)}, 81 | } 82 | 83 | @misc{tormetrics, 84 | author = {{The Tor Project}}, 85 | title = {Servers -- {Tor} metrics}, 86 | url = {https://metrics.torproject.org/networksize.html}, 87 | note = {(visited on 2017-05-09)}, 88 | } 89 | 90 | @misc{torspec, 91 | author = {Roger Dingledine and Nick Mathewson}, 92 | title = {{Tor} Protocol Specification}, 93 | url = {https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt}, 94 | note = {(visited on 2017-05-09)}, 95 | } 96 | 97 | @misc{collector, 98 | author = {{The Tor Project}}, 99 | title = {{CollecTor}}, 100 | url = {https://collector.torproject.org}, 101 | note = {(visited on 2017-05-09)}, 102 | } 103 | 104 | @inproceedings{Hastings2016a, 105 | author = {Marcella Hastings and Joshua Fried and Nadia Heninger}, 106 | title = {Weak Keys Remain Widespread in Network Devices}, 107 | booktitle = {IMC}, 108 | publisher = {ACM}, 109 | year = {2016}, 110 | url = {https://www.cis.upenn.edu/~nadiah/papers/weak-keys/weak-keys.pdf}, 111 | note = {(visited on 2017-05-09)}, 112 | } 113 | 114 | @inproceedings{Valenta2016a, 115 | author = {Luke Valenta and Shaanan Cohney and Alex Liao and Joshua Fried and Satya Bodduluri and Nadia Heninger}, 116 | title = {Factoring as a Service}, 117 | booktitle = {Financial Cryptography}, 118 | publisher = {ACM}, 119 | year = {2016}, 120 | url = {https://eprint.iacr.org/2015/1000.pdf}, 121 | note = {(visited on 2017-05-09)}, 122 | } 123 | 124 | @misc{Bernstein04, 125 | author = {Daniel J. Bernstein}, 126 | title = {How to find smooth parts of integers}, 127 | year = {2004}, 128 | url = {https://cr.yp.to/factorization/smoothparts-20040510.pdf}, 129 | note = {(visited on 2017-05-09)}, 130 | } 131 | 132 | @inproceedings{Bernstein2013a, 133 | author = {Daniel J. Bernstein and Yun-An Chang and Chen-Mou Cheng and Li-Ping Chou and Nadia Heninger and Tanja Lange and Nicko van Someren}, 134 | title = {Factoring {RSA} keys from certified smart cards: {Coppersmith} in the wild}, 135 | booktitle = {ASIACRYPT}, 136 | publisher = {Springer}, 137 | year = {2013}, 138 | url = {https://smartfacts.cr.yp.to/smartfacts-20130916.pdf}, 139 | note = {(visited on 2017-05-09)}, 140 | } 141 | 142 | % url = {https://nymity.ch/anomalous-tor-keys/pdf/Lenstra2012a.pdf}, 143 | @inproceedings{Lenstra2012a, 144 | author = {Arjen K. Lenstra and James P. Hughes and Maxime Augier and Joppe W. Bos and Thorsten Kleinjung and Christophe Wachter}, 145 | title = {Public Keys}, 146 | booktitle = {CRYPTO}, 147 | publisher = {Springer}, 148 | year = {2012}, 149 | note = {(visited on 2017-05-09)}, 150 | } 151 | 152 | @misc{fastgcd, 153 | author = {Nadia Heninger and J. Alex Halderman}, 154 | title = {fastgcd}, 155 | url = {https://factorable.net/fastgcd-1.0.tar.gz}, 156 | note = {(visited on 2017-05-09)}, 157 | } 158 | 159 | @article{Boneh1999a, 160 | author = {Dan Boneh}, 161 | title = {Twenty Years of Attacks on the {RSA} Cryptosystem}, 162 | journal = {Notices of the American Mathematical Society}, 163 | volume = {46}, 164 | number = {2}, 165 | year = {1999}, 166 | url = {http://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf}, 167 | note = {(visited on 2017-05-09)}, 168 | } 169 | 170 | @misc{scallion, 171 | author = {Eric Swanson}, 172 | title = {{Scallion} -- {GPU}-based Onion Hash generator}, 173 | url = {https://github.com/lachesis/scallion}, 174 | note = {(visited on 2017-05-09)}, 175 | } 176 | 177 | @misc{stem, 178 | author = {Damian Johnson}, 179 | title = {{Stem} Docs}, 180 | url = {https://stem.torproject.org}, 181 | note = {(visited on 2017-05-09)}, 182 | } 183 | 184 | @misc{pycrypto, 185 | author = {Dwayne Litzenberger}, 186 | title = {{PyCrypto} -- The {Python} Cryptography Toolkit}, 187 | url = {https://www.dlitz.net/software/pycrypto/}, 188 | note = {(visited on 2017-05-09)}, 189 | } 190 | 191 | @misc{ahmia, 192 | author = {Juha Nurmi}, 193 | title = {Ahmia -- Search {Tor} Hidden Services}, 194 | url = {https://ahmia.fi/onions/}, 195 | note = {(visited on 2017-05-09)}, 196 | } 197 | 198 | @inproceedings{Winter2016a, 199 | author = {Philipp Winter and Roya Ensafi and Karsten Loesing and Nick Feamster}, 200 | title = {Identifying and characterizing {Sybils} in the {Tor} network}, 201 | booktitle = {USENIX Security}, 202 | publisher = {USENIX}, 203 | year = {2016}, 204 | url = {https://nymity.ch/sybilhunting/pdf/sybilhunting-sec16.pdf}, 205 | note = {(visited on 2017-05-09)}, 206 | } 207 | 208 | @misc{OCearbhaill2013a, 209 | author = {Donncha O'Cearbhaill}, 210 | title = {Trawling {Tor} Hidden Service -- Mapping the {DHT}}, 211 | year = {2013}, 212 | url = {https://donncha.is/2013/05/trawling-tor-hidden-services/}, 213 | note = {(visited on 2017-05-09)}, 214 | } 215 | 216 | @misc{vanity-domains, 217 | author = {Philipp Winter}, 218 | title = {Are vanity onion domains a good idea?}, 219 | year = {2015}, 220 | month = oct, 221 | url = {https://moderncrypto.org/mail-archive/messaging/2015/001928.html}, 222 | note = {(visited on 2017-05-09)}, 223 | } 224 | 225 | @misc{facebook, 226 | author = {Alec Muffett}, 227 | title = {Facebook brute forcing hidden services}, 228 | year = {2014}, 229 | month = oct, 230 | url = {https://lists.torproject.org/pipermail/tor-talk/2014-October/035413.html}, 231 | note = {(visited on 2017-05-09)}, 232 | } 233 | 234 | @article{Rivest1978a, 235 | title = {A Method for Obtaining Digital Signatures and Public-Key Cryptosystems}, 236 | author = {Rivest, Ronald L. and Shamir, Adi and Adleman, Leonard}, 237 | journal = {Communications of the ACM}, 238 | volume = {21}, 239 | number = {2}, 240 | pages = {120--126}, 241 | year = {1978}, 242 | publisher = {ACM}, 243 | url = {https://people.csail.mit.edu/rivest/Rsapaper.pdf}, 244 | note = {(visited on 2017-05-09)}, 245 | } 246 | 247 | @inproceedings{Matic2015a, 248 | author = {Srdjan Matic and Platon Kotzias and Juan Caballero}, 249 | title = {{CARONTE}: Detecting Location Leaks for Deanonymizing {Tor} Hidden Services}, 250 | booktitle = {CCS}, 251 | publisher = {ACM}, 252 | year = {2015}, 253 | url = {https://software.imdea.org/~juanca/papers/caronte_ccs15.pdf}, 254 | note = {(visited on 2017-05-09)}, 255 | } 256 | 257 | @misc{torresearch, 258 | author = {{The Tor Project}}, 259 | title = {{Tor Research Home}}, 260 | url = {https://research.torproject.org}, 261 | } 262 | 263 | @misc{safety-board, 264 | author = {{The Tor Project}}, 265 | title = {{Tor} Research Safety Board}, 266 | url = {https://research.torproject.org/safetyboard.html}, 267 | note = {(visited on 2017-05-09)}, 268 | } 269 | 270 | @misc{prop224, 271 | author = {Nick Mathewson}, 272 | title = {Next-Generation Hidden Services in {Tor}}, 273 | url = {https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt}, 274 | note = {(visited on 2017-08-01)}, 275 | } 276 | 277 | @misc{Roberts2017a, 278 | author = {Laura M. Roberts}, 279 | title = {``Anomalous keys in {Tor} relays'' technical report now available}, 280 | url = {https://lists.torproject.org/pipermail/tor-dev/2017-April/012161.html}, 281 | year = {2017}, 282 | month = apr, 283 | note = {(visited on 2017-08-02)}, 284 | } 285 | 286 | @misc{prop250, 287 | author = {{The Tor Project}}, 288 | title = {{Tor} Shared Random Subsystem Specification}, 289 | url = {https://gitweb.torproject.org/torspec.git/tree/srv-spec.txt}, 290 | note = {(visited on 2017-08-02)}, 291 | } 292 | 293 | @misc{dir-spec, 294 | author = {{The Tor Project}}, 295 | title = {{Tor} directory protocol, version 3}, 296 | url = {https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt}, 297 | note = {(visited on 2017-08-02)}, 298 | } 299 | 300 | @misc{securedrop, 301 | author = {{Freedom of the Press Foundation}}, 302 | title = {{SecureDrop}}, 303 | url = {https://securedrop.org}, 304 | note = {(visited on 2017-09-19)}, 305 | } 306 | 307 | @inproceedings{Dorey2017a, 308 | author = {Kristen Dorey and Nicholas Chang-Fong and Aleksander Essex}, 309 | title = {Indiscreet Logs: {Diffie-Hellman} Backdoors in {TLS}}, 310 | booktitle = {NDSS}, 311 | year = {2017}, 312 | publisher = {Internet Society}, 313 | url = {https://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/ndss2017_04A-2_Dorey_paper.pdf}, 314 | note = {(visited on 2017-09-19)}, 315 | } 316 | 317 | @inproceedings{Valenta2017a, 318 | author = {Luke Valenta and David Adrian and Antonio Sanso and Shaanan Cohney and Joshua Fried and Marcella Hastings and J. Alex Halderman and Nadia Heninger}, 319 | title = {Measuring small subgroup attacks against {Diffie-Hellman}}, 320 | booktitle = {NDSS}, 321 | year = {2017}, 322 | publisher = {Internet Society}, 323 | url = {https://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/ndss2017_04A-1_Valenta_paper_0.pdf}, 324 | note = {(visited on 2017-09-19)}, 325 | } 326 | 327 | @inproceedings{Adrian2015a, 328 | author = {David Adrian and Karthikeyan Bhargavan and Zakir Durumeric and Pierrick Gaudry and Matthew Green and J. Alex Halderman and Nadia Heninger and Drew Springall and Emmanuel Thom\'e and Luke Valenta and Benjamin VanderSloot and Eric Wustrow and Santiago Zanella-B\'eguelin and Paul Zimmermann}, 329 | title = {Imperfect Forward Secrecy: How {Diffie-Hellman} Fails in Practice}, 330 | booktitle = {CCS}, 331 | publisher = {ACM}, 332 | year = {2015}, 333 | url = {https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf}, 334 | note = {(visited on 2017-09-22)}, 335 | } 336 | 337 | @misc{nmapdhscript, 338 | author = {Jacob Gajek}, 339 | title = {ssl-dh-params}, 340 | url = {https://nmap.org/nsedoc/scripts/ssl-dh-params.html}, 341 | note = {(visited on 2017-09-22)}, 342 | } 343 | 344 | -------------------------------------------------------------------------------- /paper/related.tex: -------------------------------------------------------------------------------- 1 | \section{Related work} 2 | \label{sec:related} 3 | In 2012, Lenstra \ea~\cite{Lenstra2012a} and Heninger \ea~\cite{Heninger2012a} 4 | independently analyzed a large set of RSA public keys used for TLS, SSH, and 5 | PGP. Both groups discovered that many keys shared prime factors, allowing an 6 | attacker to efficiently compute the corresponding private keys. The researchers 7 | showed that the root cause was weak randomness at the time of key generation: 8 | Many Internet-connected devices lack entropy sources, resulting in predictable 9 | keys. 10 | 11 | One year later, Bernstein \ea~\cite{Bernstein2013a} showed similar flaws in 12 | Taiwan's national ``Citizen Digital Certificate'' database. Among more than two 13 | million 1024-bit RSA keys, the authors discovered 184 vulnerable keys, 103 of 14 | which shared prime factors. The authors could break the remaining 81 keys by 15 | applying a Coppersmith-type partial-key-recovery 16 | attack~\cite{Coppersmith1996a,Coppersmith1997a}. 17 | 18 | Valenta \ea~\cite{Valenta2016a} optimized popular implementations for integer 19 | factorization, allowing them to factor 512-bit RSA public keys on Amazon EC2 in 20 | under four hours for only \$75. The authors then moved on to survey the RSA key 21 | sizes that are used in popular protocols such as HTTPS, DNSSEC, and SSH, 22 | discovering numerous keys of only 512 bits. 23 | 24 | Most recently, in 2016, Hastings \ea~\cite{Hastings2016a} revisited the problem 25 | of weak keys and investigated how many such keys were still on the Internet 26 | four years after the initial studies. The authors found that many vendors and 27 | device owners never patched their vulnerable devices. Surprisingly, the number 28 | of vulnerable devices has actually \emph{increased} since 2012. 29 | -------------------------------------------------------------------------------- /paper/results.tex: -------------------------------------------------------------------------------- 1 | \section{Results} 2 | \label{sec:results} 3 | We present our results in four parts, starting with shared prime factors 4 | (Section~\ref{sec:shared-primes}), followed by shared moduli 5 | (Section~\ref{sec:shared-moduli}), unusual exponents 6 | (Section~\ref{sec:unusual-exponents}), and finally, targeted onion services 7 | (Section~\ref{sec:targeted-onion-services}). 8 | 9 | \subsection{Shared prime factors} 10 | \label{sec:shared-primes} 11 | Among all 588,945 identity keys, fastgcd found that 3,557 (0.6\%) 12 | moduli share prime factors. We believe that 3,555 of these keys were all 13 | controlled by a single research group, and upon contacting the authors of the 14 | Security \& Privacy 2013 paper entitled ``Trawling for Tor hidden 15 | services''~\cite{Biryukov2013a}, we received confirmation that these relays 16 | were indeed run by their research group. The authors informed us that the weak 17 | keys were caused by a shortcoming in their key generation tool. The issue 18 | stemmed from the fact that their tool first generated thousands of prime numbers 19 | and then computed multiple moduli using combinations of those prime numbers in a 20 | greedy fashion without ensuring that the same primes were not reused. Because 21 | of the following shared properties, we are confident that all relays were 22 | operated by the researchers: 23 | 24 | \begin{enumerate} 25 | \item All relays were online either between November 11, 2012 and 26 | November 16, 2012 or between January 14, 2013 and February 6, 2013, 27 | suggesting two separate experiments. We verified this by checking how 28 | long the relays stayed in the Tor network consensus. The Tor consensus 29 | is updated hourly and documents which relays are available at a 30 | particular time. This data is archived by The Tor Project and is made 31 | publicly available on the CollecTor platform~\cite{collector}. 32 | 33 | \item All relays exhibited a predictable port assignment scheme. In 34 | particular, we observed ports \{7003, 7007, \dots, 7043, 7047\} and 35 | \{8003, 8007, \dots, 8043, 8047\}. 36 | 37 | \item Except for two machines that were located in Russia and Luxembourg, 38 | all machines were hosted in Amazon's EC2 address space. All machines 39 | except the one located in Luxembourg used Tor version 0.2.2.37. 40 | 41 | \item All physical machines had multiple fingerprints. 1,321 of these 3,557 42 | relays were previously characterized by Winter 43 | \ea~\cite[\S~5.1]{Winter2016a}. 44 | \end{enumerate} 45 | 46 | The remaining two keys belonged to a relay named ``Desaster\-Blaster,'' whose 47 | origins we could not determine. Its router descriptor indicates that the relay 48 | has been hosted on a MIPS machine which might suggest an embedded device with a 49 | weak random number generator: 50 | 51 | {\footnotesize 52 | \begin{verbatim} 53 | router DesasterBlaster 62.226.55.122 9001 0 0 54 | platform Tor 0.2.2.13-alpha on Linux mips 55 | \end{verbatim} 56 | } 57 | 58 | To further investigate, we checked whether the relay ``Desaster\-Blaster'' shares 59 | prime factors with any other relays. It appears that the relay has rotated 60 | multiple identity keys, and it only shares prime factors with its own keys. 61 | Unfortunately the relay did not have any contact information configured which is 62 | why we could not get in touch with its operator. 63 | 64 | 65 | \subsection{Shared moduli} 66 | \label{sec:shared-moduli} 67 | In addition to finding shared prime factors, we discovered relays that share a 68 | \emph{modulus}, giving them the ability to calculate each other's private keys. 69 | With $p$, $q$, and each other's $e$s in hand, the two parties can compute 70 | each other's decryption exponent $d$, at which point both parties now know the 71 | private decryption keys. 72 | 73 | Table~\ref{tab:moduli} shows these ten relays with shared moduli clustered into 74 | four groups. The table shows the relays' truncated, four-byte fingerprint, IP 75 | addresses, and RSA exponents. Note that the Tor client hard-codes the RSA 76 | exponent to 65,537~\cite[\S~0.3]{torspec}, a recommended value that is resistant 77 | to attacks against low public exponents~\cite[\S~4]{Boneh1999a}. Any value 78 | other than 65,537 indicates non-standard key generation. All IP addresses were 79 | hosted by OVH, a popular French hosting provider, and some of the IP addresses 80 | hosted two relays, as our color coding indicates. Finally, each group shared a 81 | four- or five-digit prefix in their fingerprints. We believe that a single 82 | attacker controlled all these relays with the intention to manipulate the 83 | distributed hash table that powers onion services~\cite{Biryukov2013a}---the 84 | shared fingerprint prefix is an indication. Because the modulus is identical, 85 | we suspect that the attackers iterated over the relays' RSA exponents to come up 86 | with the shared prefix. The Tor Project informed us that it discovered and 87 | blocked these relays in August 2014 when they first came online. 88 | 89 | \begin{table}[t] 90 | \caption{Four groups of relays that have a shared modulus. All relays 91 | further share a fingerprint prefix in groups of two or three, presumably to 92 | manipulate Tor's distributed hash table.} 93 | \label{tab:moduli} 94 | 95 | \centering 96 | \begin{tabular}{l l r} 97 | \toprule 98 | 99 | Short fingerprint & IP address & Exponent \\ 100 | \midrule 101 | 102 | \texttt{\setlength{\fboxsep}{0pt}% 103 | \colorbox{highlight1}{\strut 838A}296A} & 188.165.164.163 & 104 | 1,854,629 \\ 105 | 106 | \texttt{\setlength{\fboxsep}{0pt}% 107 | \colorbox{highlight1}{\strut 838A}305F} & 108 | {\setlength{\fboxsep}{0pt}\colorbox{highlight3}{\strut 188.165.26.13}} & 109 | 718,645 \\ 110 | 111 | \texttt{\setlength{\fboxsep}{0pt}% 112 | \colorbox{highlight1}{\strut 838A}71E2} & 113 | {\setlength{\fboxsep}{0pt}\colorbox{highlight2}{\strut 178.32.143.175}} & 114 | 220,955 \\ 115 | 116 | \midrule 117 | 118 | \texttt{\setlength{\fboxsep}{0pt}% 119 | \colorbox{highlight1}{\strut 2249E}B42} & 120 | {\setlength{\fboxsep}{0pt}\colorbox{highlight3}{\strut 188.165.26.13}} & 121 | 4,510,659 \\ 122 | 123 | \texttt{\setlength{\fboxsep}{0pt}% 124 | \colorbox{highlight1}{\strut 2249E}C78} & 125 | {\setlength{\fboxsep}{0pt}\colorbox{highlight2}{\strut 178.32.143.175}} & 126 | 1,074,365 \\ 127 | 128 | \midrule 129 | 130 | \texttt{\setlength{\fboxsep}{0pt}% 131 | \colorbox{highlight1}{\strut E1EF}A388} & 188.165.3.63 & 132 | 18,177 \\ 133 | 134 | \texttt{\setlength{\fboxsep}{0pt}% 135 | \colorbox{highlight1}{\strut E1EF}8985} & 136 | {\setlength{\fboxsep}{0pt}\colorbox{highlight4}{\strut 188.165.138.181}} & 137 | 546,019 \\ 138 | 139 | \texttt{\setlength{\fboxsep}{0pt}% 140 | \colorbox{highlight1}{\strut E1EF}9EB8} & 141 | {\setlength{\fboxsep}{0pt}\colorbox{highlight5}{\strut 5.39.122.66}} & 142 | 73,389 \\ 143 | 144 | \midrule 145 | 146 | \texttt{\setlength{\fboxsep}{0pt}% 147 | \colorbox{highlight1}{\strut 410B}A17E} & 148 | {\setlength{\fboxsep}{0pt}\colorbox{highlight4}{\strut 188.165.138.181}} & 149 | 1,979,465 \\ 150 | 151 | \texttt{\setlength{\fboxsep}{0pt}% 152 | \colorbox{highlight1}{\strut 410B}B962} & 153 | {\setlength{\fboxsep}{0pt}\colorbox{highlight5}{\strut 5.39.122.66}} & 154 | 341,785 \\ 155 | 156 | \bottomrule 157 | \end{tabular} 158 | \end{table} 159 | 160 | \subsection{Unusual exponents} 161 | \label{sec:unusual-exponents} 162 | Having accidentally found a number of relays with non-standard exponents in 163 | Section~\ref{sec:shared-moduli}, we checked if our dataset featured more relays 164 | with exponents other than 65,537. Non-standard exponents may indicate that a 165 | relay was after a specific fingerprint in order to position itself in Tor's hash 166 | ring. To obtain a fingerprint with a given prefix, an adversary repeatedly has 167 | to modify any of the underlying key material $p$, $q$, or $e$ until they result 168 | in the desired prefix. Repeated modification of $e$ is significantly more 169 | efficient than modifying $p$ or $q$ because it is costly to verify if a large 170 | number is prime. Leveraging this method, the tool Scallion~\cite{scallion} 171 | generates vanity onion service domains by iterating over the service's public 172 | exponent. 173 | 174 | Among all of our 3.7 million keys, 122 possessed an exponent other than 65,537. 175 | One relay had both non-standard identity \emph{and} onion key exponents while 176 | all remaining relays only had non-standard identity key exponents. Ten of these 177 | relays further had a shared modulus, which we discuss in 178 | Section~\ref{sec:shared-moduli}. Assuming that these relays positioned 179 | themselves in the hash ring to attack an onion service, we wanted to find out 180 | what onion services they targeted. One can identify the victims by first 181 | compiling a comprehensive list of onion services and then determining each 182 | service's position in the hash ring at the time the malicious HSDirs were 183 | online. 184 | 185 | \subsection{Identifying targeted onion services} 186 | \label{sec:targeted-onion-services} 187 | 188 | We obtained a list of onion services by augmenting the list of the Ahmia 189 | search engine~\cite{ahmia} with services that we discovered via Google searches 190 | and by contacting researchers who have done similar work~\cite{Matic2015a}. We 191 | ended up with a list of 17,198 onion services that were online at some point in 192 | time. Next, we developed a tool that takes as input our list of onion services 193 | and the malicious HSDirs we discovered.\footnote{Both the tool and our list of 194 | onion services are available online at 195 | \url{https://nymity.ch/anomalous-tor-keys/}.} The tool then calculates all 196 | descriptors these onion services ever generated and checks if any HSDir shared 197 | five or more hex digits in its fingerprint prefix with the onion service's 198 | descriptor. We chose the threshold of five manually because it is unlikely to 199 | happen by chance yet easy to create a five-digit collision. 200 | 201 | It is difficult to identify all targeted onion services because \first our list 202 | of onion services does not tell us when a service was online, \second an HSDir 203 | could be responsible for an onion service simply by chance rather than on 204 | purpose, resulting in a false positive, and \third our list of onion services is 205 | not exhaustive, so we are bound to miss victims. Nevertheless our tool 206 | identified four onion services (see Table~\ref{tab:targeted}) for which we have 207 | strong evidence that they were purposely targeted. While HSDirs are frequently 208 | in the vicinity of an onion service's descriptor by accident, the probability of 209 | being in its vicinity for several days in a row or cover both replicas by chance 210 | is negligible. Table~\ref{tab:collisions} shows all partial collisions in 211 | detail. Because none of these four services seem to have been intended for 212 | private use, we are comfortable publishing them. 213 | 214 | \begin{table}[t] 215 | \caption{The four onion services that were most likely targeted at some 216 | point. The second column indicates if only one or both replicas were 217 | attacked while the third column shows the duration of the attack.} 218 | \label{tab:targeted} 219 | \centering 220 | \begin{tabular}{l c l} 221 | \toprule 222 | Onion service & Replicas & Attack duration \\ 223 | \midrule 224 | \texttt{22u75kqyl666joi2.onion} & 2 & Two consecutive days \\ 225 | \texttt{n3q7l52nfpm77vnf.onion} & 2 & Six non-consecutive days \\ 226 | \texttt{silkroadvb5piz3r.onion} & 1 & Nine mostly consecutive days \\ 227 | \texttt{thehub7gqe43miyc.onion} & 2 & One day \\ 228 | \bottomrule 229 | \end{tabular} 230 | \end{table} 231 | 232 | \begin{description} 233 | \item[\texttt{22u75kqyl666joi2.onion}] The service appears to be offline 234 | today, so we were unable to see for ourselves what it hosted. According 235 | to cached index pages we found online, the onion service used to host a 236 | technology-focused forum in Chinese. A set of relays targeted the onion 237 | service on both August 14 and 15, 2015 by providing nine out of the 238 | total of twelve responsible HSDirs. 239 | 240 | \item[\texttt{n3q7l52nfpm77vnf.onion}] As of February 2017, the service is 241 | still online, hosting the ``Marxists Internet Archive,'' an online 242 | archive of literature.\footnote{The onion service seems to be identical 243 | to the website \url{https://www.marxists.org} (visited on 2017-05-09).} 244 | A set of relays targeted the onion service from November 27 to December 245 | 4, 2016. The malicious HSDirs acted inconsistently, occasionally 246 | targeting only one replica. 247 | 248 | \item[\texttt{silkroadvb5piz3r.onion}] The onion service used to host the 249 | Silk Road marketplace, whose predominant use was a market for narcotics. 250 | The service was targeted by a set of relays from May 21 to June 3, 2013. 251 | The HSDirs were part of a measurement experiment that resulted in a blog 252 | post~\cite{OCearbhaill2013a}. 253 | 254 | \item[\texttt{thehub7gqe43miyc.onion}] The onion service used to host a 255 | discussion forum, ``The Hub,'' focused on darknet markets. A set of 256 | relays targeted both of The Hub's replicas from August 22, 2015. 257 | \end{description} 258 | 259 | Our data cannot provide insight into what the HSDirs did once they controlled 260 | the replicas of the onion services they targeted. The HSDirs could have counted 261 | the number of client requests, refused to serve the onion service's descriptor 262 | to take it offline, or correlate client requests with guard relay traffic in 263 | order to deanonymize onion service visitors as it was done by the CMU/SEI 264 | researchers in 2014~\cite{Dingledine2014a}. Since these attacks were 265 | short-lived we find it unlikely that they were meant to take offline the 266 | respective onion services. 267 | -------------------------------------------------------------------------------- /web/anomalous-tor-keys.bib: -------------------------------------------------------------------------------- 1 | @techreport{Kadianakis2017a, 2 | author = {George Kadianakis and Claudia V. Roberts and Laura M. Roberts and Philipp Winter}, 3 | title = {Anomalous keys in {Tor} relays}, 4 | institution = {}, 5 | month = apr, 6 | year = {2017}, 7 | url = {https://nymity.ch/anomalous-tor-keys/anomalous-tor-keys.pdf}, 8 | } 9 | -------------------------------------------------------------------------------- /web/bibliography/author.html: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | 6 | 7 | 8 | Open access bibliography 9 | 59 | 60 | 61 | 62 | 63 |
64 |
65 |

Open access bibliography

66 |

for the paper “Anomalous keys in Tor relays”

67 | Sort by: (reverse) year, 68 | (reverse) author 69 |
70 |
71 | 78 |
    79 |
  • 80 | Public Keys 81 | [url, cached pdf, bib]
    82 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 83 |
    • 84 |
85 | 97 | 104 |
    105 |
  • 106 | Factoring as a Service 107 | [pdf, cached pdf, bib]
    108 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 109 |
    • 110 |
111 | 118 |
    119 |
  • 120 | Public Keys 121 | [url, cached pdf, bib]
    122 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 123 |
    • 124 |
125 | 132 | 139 | 146 | 153 |
    154 |
  • 155 | Factoring as a Service 156 | [pdf, cached pdf, bib]
    157 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 158 |
    • 159 |
160 | 172 | 189 | 196 | 203 | 210 | 222 | 229 | 241 | 248 | 275 | 282 |
    283 |
  • 284 | Public Keys 285 | [url, cached pdf, bib]
    286 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 287 |
    • 288 |
289 | 296 |
    297 |
  • 298 | Stem Docs 299 | [url, bib]
    300 | Damian Johnson
    Miscellaneous, 301 |
    • 302 |
303 |
    304 |
  • 305 | Public Keys 306 | [url, cached pdf, bib]
    307 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 308 |
    • 309 |
310 | 317 | 324 |
    325 |
  • 326 | Public Keys 327 | [url, cached pdf, bib]
    328 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 329 |
    • 330 |
331 |
    332 |
  • 333 | Factoring as a Service 334 | [pdf, cached pdf, bib]
    335 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 336 |
    • 337 |
338 | 345 | 352 | 359 | 366 | 373 | 380 | 402 | 409 | 416 | 423 | 430 | 437 | 444 | 451 |
    452 |
  • 453 | Factoring as a Service 454 | [pdf, cached pdf, bib]
    455 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 456 |
    • 457 |
458 |
    459 |
  • 460 | Public Keys 461 | [url, cached pdf, bib]
    462 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 463 |
    • 464 |
465 | 472 | 484 | 491 |
492 | 493 |
494 | Bibliography generated by bibliograpy. 495 |
496 | 497 | 498 | 499 | -------------------------------------------------------------------------------- /web/bibliography/author_reverse.html: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | 6 | 7 | 8 | Open access bibliography 9 | 59 | 60 | 61 | 62 | 63 |
64 |
65 |

Open access bibliography

66 |

for the paper “Anomalous keys in Tor relays”

67 | Sort by: (reverse) year, 68 | (reverse) author 69 |
70 |
71 | 78 | 90 | 97 |
    98 |
  • 99 | Public Keys 100 | [url, cached pdf, bib]
    101 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 102 |
    • 103 |
104 |
    105 |
  • 106 | Factoring as a Service 107 | [pdf, cached pdf, bib]
    108 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 109 |
    • 110 |
111 | 118 | 125 | 132 | 139 | 146 | 153 | 160 | 182 | 189 | 196 | 203 | 210 | 217 | 224 |
    225 |
  • 226 | Factoring as a Service 227 | [pdf, cached pdf, bib]
    228 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 229 |
    • 230 |
231 |
    232 |
  • 233 | Public Keys 234 | [url, cached pdf, bib]
    235 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 236 |
    • 237 |
238 | 245 | 252 |
    253 |
  • 254 | Public Keys 255 | [url, cached pdf, bib]
    256 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 257 |
    • 258 |
259 |
    260 |
  • 261 | Stem Docs 262 | [url, bib]
    263 | Damian Johnson
    Miscellaneous, 264 |
    • 265 |
266 | 273 |
    274 |
  • 275 | Public Keys 276 | [url, cached pdf, bib]
    277 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 278 |
    • 279 |
280 | 287 | 314 | 321 | 333 | 340 | 352 | 359 | 366 | 373 | 390 | 402 |
    403 |
  • 404 | Factoring as a Service 405 | [pdf, cached pdf, bib]
    406 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 407 |
    • 408 |
409 | 416 | 423 | 430 | 437 |
    438 |
  • 439 | Public Keys 440 | [url, cached pdf, bib]
    441 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 442 |
    • 443 |
444 | 451 |
    452 |
  • 453 | Factoring as a Service 454 | [pdf, cached pdf, bib]
    455 | Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Fried, Satya Bodduluri, Nadia Heninger
    In Proc. of: Financial Cryptography, 2016, ACM 456 |
    • 457 |
458 | 465 | 477 |
    478 |
  • 479 | Public Keys 480 | [url, cached pdf, bib]
    481 | Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter
    In Proc. of: CRYPTO, 2012, Springer 482 |
    • 483 |
484 | 491 |
492 | 493 |
494 | Bibliography generated by bibliograpy. 495 |
496 | 497 | 498 | 499 | -------------------------------------------------------------------------------- /web/bibliography/bibtex.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | BibTeX entries 8 | 9 | 10 | 
 11 | @inproceedings{Jansen2012a,
 12 |   author = {Rob Jansen and Nicholas Hopper},
 13 |   url = {http://www.robgjansen.com/publications/shadow-ndss2012.pdf},
 14 |   publisher = {Internet Society},
 15 |   booktitle = {NDSS},
 16 |   year = {2012},
 17 |   title = {{Shadow}: Running {Tor} in a Box for Accurate and Efficient Experimentation},
 18 | }
 19 | 
 20 | @misc{Dingledine2014a,
 21 |   author = {Roger Dingledine},
 22 |   url = {https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack/},
 23 |   month = {July},
 24 |   year = {2014},
 25 |   title = {{Tor} security advisory: ``relay early'' traffic confirmation attack},
 26 | }
 27 | 
 28 | @article{Goldberg2013a,
 29 |   author = {Ian Goldberg and Douglas Stebila and Berkant Ustaoglu},
 30 |   title = {Anonymity and one-way authentication in key exchange protocols},
 31 |   url = {https://nymity.ch/anomalous-tor-keys/pdf/Goldberg2013a.pdf},
 32 |   journal = {Designs, Codes and Cryptography},
 33 |   number = {2},
 34 |   volume = {67},
 35 |   year = {2013},
 36 |   pages = {245--269},
 37 | }
 38 | 
 39 | @inproceedings{Coppersmith1996a,
 40 |   author = {Don Coppersmith},
 41 |   publisher = {Springer},
 42 |   title = {Finding a Small Root of a Bivariate Integer Equation; Factoring with High Bits Known},
 43 |   url = {https://nymity.ch/anomalous-tor-keys/pdf/Coppersmith1996a.pdf},
 44 |   booktitle = {EUROCRYPT},
 45 |   year = {1996},
 46 |   pages = {178--189},
 47 | }
 48 | 
 49 | @article{Coppersmith1997a,
 50 |   author = {Don Coppersmith},
 51 |   title = {Small Solutions to Polynomial Equations, and Low Exponent {RSA} Vulnerabilities},
 52 |   url = {https://www.di.ens.fr/~fouque/ens-rennes/coppersmith.pdf},
 53 |   journal = {Journal of Cryptology},
 54 |   number = {4},
 55 |   volume = {10},
 56 |   year = {1997},
 57 |   pages = {233--260},
 58 | }
 59 | 
 60 | @inproceedings{Biryukov2013a,
 61 |   author = {Alex Biryukov and Ivan Pustogarov and Ralf-Philipp Weinmann},
 62 |   url = {http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf},
 63 |   publisher = {IEEE},
 64 |   booktitle = {Security and Privacy},
 65 |   year = {2013},
 66 |   title = {Trawling for {Tor} Hidden Services: Detection, Measurement, Deanonymization},
 67 | }
 68 | 
 69 | @inproceedings{Heninger2012a,
 70 |   author = {Nadia Heninger and Zakir Durumeric and Eric Wustrow and J. Alex Halderman},
 71 |   url = {https://factorable.net/weakkeys12.extended.pdf},
 72 |   publisher = {USENIX},
 73 |   booktitle = {USENIX Security},
 74 |   year = {2012},
 75 |   title = {Mining Your {Ps} and {Qs}: Detection of Widespread Weak Keys in Network Devices},
 76 | }
 77 | 
 78 | @misc{tormetrics,
 79 |   author = {{The Tor Project}},
 80 |   url = {https://metrics.torproject.org/networksize.html},
 81 |   title = {Servers -- {Tor} metrics},
 82 | }
 83 | 
 84 | @misc{torspec,
 85 |   author = {Roger Dingledine and Nick Mathewson},
 86 |   url = {https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt},
 87 |   title = {{Tor} Protocol Specification},
 88 | }
 89 | 
 90 | @misc{collector,
 91 |   author = {{The Tor Project}},
 92 |   url = {https://collector.torproject.org},
 93 |   title = {{CollecTor}},
 94 | }
 95 | 
 96 | @inproceedings{Hastings2016a,
 97 |   author = {Marcella Hastings and Joshua Fried and Nadia Heninger},
 98 |   url = {https://www.cis.upenn.edu/~nadiah/papers/weak-keys/weak-keys.pdf},
 99 |   publisher = {ACM},
100 |   booktitle = {IMC},
101 |   year = {2016},
102 |   title = {Weak Keys Remain Widespread in Network Devices},
103 | }
104 | 
105 | @inproceedings{Valenta2016a,
106 |   author = {Luke Valenta and Shaanan Cohney and Alex Liao and Joshua Fried and Satya Bodduluri and Nadia Heninger},
107 |   url = {https://eprint.iacr.org/2015/1000.pdf},
108 |   publisher = {ACM},
109 |   booktitle = {Financial Cryptography},
110 |   year = {2016},
111 |   title = {Factoring as a Service},
112 | }
113 | 
114 | @misc{Bernstein04,
115 |   author = {Daniel J. Bernstein},
116 |   url = {https://cr.yp.to/factorization/smoothparts-20040510.pdf},
117 |   year = {2004},
118 |   title = {How to find smooth parts of integers},
119 | }
120 | 
121 | @inproceedings{Bernstein2013a,
122 |   author = {Daniel J. Bernstein and Yun-An Chang and Chen-Mou Cheng and Li-Ping Chou and Nadia Heninger and Tanja Lange and Nicko Someren},
123 |   url = {https://smartfacts.cr.yp.to/smartfacts-20130916.pdf},
124 |   publisher = {Springer},
125 |   booktitle = {ASIACRYPT},
126 |   year = {2013},
127 |   title = {Factoring {RSA} keys from certified smart cards: {Coppersmith} in the wild},
128 | }
129 | 
130 | @inproceedings{Lenstra2012a,
131 |   author = {Arjen K. Lenstra and James P. Hughes and Maxime Augier and Joppe W. Bos and Thorsten Kleinjung and Christophe Wachter},
132 |   url = {http://dl.acm.org.sci-hub.io/citation.cfm?id=2954229},
133 |   publisher = {Springer},
134 |   booktitle = {CRYPTO},
135 |   year = {2012},
136 |   title = {Public Keys},
137 | }
138 | 
139 | @misc{fastgcd,
140 |   author = {Nadia Heninger and J. Alex Halderman},
141 |   url = {https://factorable.net/fastgcd-1.0.tar.gz},
142 |   title = {fastgcd},
143 | }
144 | 
145 | @article{Boneh1999a,
146 |   author = {Dan Boneh},
147 |   title = {Twenty Years of Attacks on the {RSA} Cryptosystem},
148 |   url = {http://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf},
149 |   journal = {Notices of the American Mathematical Society},
150 |   number = {2},
151 |   volume = {46},
152 |   year = {1999},
153 | }
154 | 
155 | @misc{scallion,
156 |   author = {Eric Swanson},
157 |   url = {https://github.com/lachesis/scallion},
158 |   title = {{Scallion} -- {GPU}-based Onion Hash generator},
159 | }
160 | 
161 | @misc{stem,
162 |   author = {Damian Johnson},
163 |   url = {https://stem.torproject.org},
164 |   title = {{Stem} Docs},
165 | }
166 | 
167 | @misc{pycrypto,
168 |   author = {Dwayne Litzenberger},
169 |   url = {https://www.dlitz.net/software/pycrypto/},
170 |   title = {{PyCrypto} -- The {Python} Cryptography Toolkit},
171 | }
172 | 
173 | @misc{ahmia,
174 |   author = {Juha Nurmi},
175 |   url = {https://ahmia.fi/onions/},
176 |   title = {Ahmia -- Search {Tor} Hidden Services},
177 | }
178 | 
179 | @inproceedings{Winter2016a,
180 |   author = {Philipp Winter and Roya Ensafi and Karsten Loesing and Nick Feamster},
181 |   url = {https://nymity.ch/sybilhunting/pdf/sybilhunting-sec16.pdf},
182 |   publisher = {USENIX},
183 |   booktitle = {USENIX Security},
184 |   year = {2016},
185 |   title = {Identifying and characterizing {Sybils} in the {Tor} network},
186 | }
187 | 
188 | @misc{OCearbhaill2013a,
189 |   author = {Donncha O'Cearbhaill},
190 |   url = {https://donncha.is/2013/05/trawling-tor-hidden-services/},
191 |   year = {2013},
192 |   title = {Trawling {Tor} Hidden Service -- Mapping the {DHT}},
193 | }
194 | 
195 | @misc{vanity-domains,
196 |   author = {Philipp Winter},
197 |   month = {October},
198 |   url = {https://moderncrypto.org/mail-archive/messaging/2015/001928.html},
199 |   year = {2015},
200 |   title = {Are vanity onion domains a good idea?},
201 | }
202 | 
203 | @misc{facebook,
204 |   author = {Roger Dingledine},
205 |   month = {October},
206 |   url = {https://lists.torproject.org/pipermail/tor-talk/2014-October/035412.html},
207 |   year = {2014},
208 |   title = {Facebook brute forcing hidden services},
209 | }
210 | 
211 | @article{Rivest1978a,
212 |   author = {Ronald L. Rivest and Adi Shamir and Leonard Adleman},
213 |   publisher = {ACM},
214 |   title = {A Method for Obtaining Digital Signatures and Public-Key Cryptosystems},
215 |   url = {https://people.csail.mit.edu/rivest/Rsapaper.pdf},
216 |   journal = {Communications of the ACM},
217 |   number = {2},
218 |   volume = {21},
219 |   year = {1978},
220 |   pages = {120--126},
221 | }
222 | 
223 | @inproceedings{Matic2015a,
224 |   author = {Srdjan Matic and Platon Kotzias and Juan Caballero},
225 |   url = {https://software.imdea.org/~juanca/papers/caronte_ccs15.pdf},
226 |   publisher = {ACM},
227 |   booktitle = {CCS},
228 |   year = {2015},
229 |   title = {{CARONTE}: Detecting Location Leaks for Deanonymizing {Tor} Hidden Services},
230 | }
231 | 
232 | @misc{torresearch,
233 |   author = {{The Tor Project}},
234 |   url = {https://research.torproject.org},
235 |   title = {{Tor Research Home}},
236 | }
237 | 
238 | @misc{safety-board,
239 |   author = {{The Tor Project}},
240 |   url = {https://research.torproject.org/safetyboard.html},
241 |   title = {{Tor} Research Safety Board},
242 | }
243 |
244 | 245 | -------------------------------------------------------------------------------- /web/bibliography/index.html: -------------------------------------------------------------------------------- 1 | year_reverse.html -------------------------------------------------------------------------------- /web/bibliography/pdf: -------------------------------------------------------------------------------- 1 | ../pdf -------------------------------------------------------------------------------- /web/bibliography/year.html: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | 6 | 7 | 8 | Open access bibliography 9 | 59 | 60 | 61 | 62 | 63 |
64 |
65 |

Open access bibliography

66 |

for the paper “Anomalous keys in Tor relays”

67 | Sort by: (reverse) year, 68 | (reverse) author 69 |
70 |
71 | 128 | 135 | 142 | 149 | 156 | 173 | 195 | 207 | 219 | 236 |
237 | 238 |
239 | Bibliography generated by bibliograpy. 240 |
241 | 242 | 243 | 244 | -------------------------------------------------------------------------------- /web/bibliography/year_reverse.html: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | 6 | 7 | 8 | Open access bibliography 9 | 59 | 60 | 61 | 62 | 63 |
64 |
65 |

Open access bibliography

66 |

for the paper “Anomalous keys in Tor relays”

67 | Sort by: (reverse) year, 68 | (reverse) author 69 |
70 |
71 | 88 | 100 | 112 | 134 | 151 | 158 | 165 | 172 | 179 | 186 | 238 |
239 | 240 |
241 | Bibliography generated by bibliograpy. 242 |
243 | 244 | 245 | 246 | -------------------------------------------------------------------------------- /web/data/anomalous-keys.tar.xz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/data/anomalous-keys.tar.xz -------------------------------------------------------------------------------- /web/data/targeted-onion-services.tar.xz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/data/targeted-onion-services.tar.xz -------------------------------------------------------------------------------- /web/img/claudia.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/img/claudia.png -------------------------------------------------------------------------------- /web/img/george.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/img/george.png -------------------------------------------------------------------------------- /web/img/laura.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/img/laura.png -------------------------------------------------------------------------------- /web/img/paper-thumb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/img/paper-thumb.png -------------------------------------------------------------------------------- /web/img/philipp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/img/philipp.png -------------------------------------------------------------------------------- /web/index.html: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | 6 | 7 | 8 | Anomalous keys in Tor relays 9 | 10 | 11 | 12 | 13 | 14 |
15 |

Anomalous keys in Tor relays

16 | 17 | Overview  •  18 | Writing  •  19 | Code  •  20 | Data  •  21 | Contact 22 |
23 | 24 |
25 | 26 |

Overview

27 |

28 | Counting 29 | almost 7,000 relays, 30 | the Tor network 31 | is one of the largest volunteer-run anonymity networks operating today. Most of 32 | the volunteers who operate these relays choose to remain anonymous, and little 33 | is known about how they set up or operate their relays. As a result, it is not 34 | clear if all relays correctly generated the cryptographic key material that is 35 | needed to participate in the Tor network. Key generation issues can have 36 | devastating consequences, and led to severe vulnerabilities 37 | in 38 | the 39 | past, 40 | emphasizing the importance of knowing if the Tor network is affected by the same 41 | weaknesses. 42 |

43 | 44 |

45 | In this research project, we took a closer look at the cryptographic keys of Tor 46 | relays. Drawing on a 47 | dataset 48 | containing more than 3.7 million Tor relay public keys over the past 10 years, 49 | (i) we checked if any relays share prime factors or moduli, (ii) 50 | we identified relays that used non-standard RSA exponents, and (iii) we 51 | characterized malicious relays that we discovered in the first two steps. Our 52 | experiments revealed that ten relays shared moduli, and 3,557 relays—most 53 | part of a research project—shared prime factors, allowing adversaries to 54 | reconstruct their private keys. Fortunately, all the relays we found with weak keys 55 | have been absent from the Tor network for years. We further discovered 122 relays that used 56 | non-standard RSA exponents, presumably in an attempt to attack onion services. 57 | By simulating how onion services are positioned in Tor’s distributed hash 58 | table, we could identify four onion services that were likely targeted by these 59 | malicious relays. 60 |

61 | 62 |

63 | What does our work mean for Tor users? There is no need for concern. While we 64 | discovered that some relays were vulnerable in the past, these relays are no 65 | longer online, and there is no reason to believe that the vulnerabilities were 66 | exploited. In addition to demonstrating these issues, we suggest 67 | countermeasures that The Tor Project can adopt to find vulnerable relays early, 68 | and remove them from the network. As a result, our work further strengthens the 69 | security of the Tor network. 70 |

71 | 72 |

Writing

73 |

74 | To date, the main outcome of this research project is a (not yet peer-reviewed) 75 | technical report that we published in April 2017: 76 |

77 | 78 | 87 | 88 |

Code

89 |

90 | Our 91 | GitHub repository 92 | contains the LaTeX code of our paper as well as our Python and Go code snippets: 93 |

94 | 95 | 
 96 | git clone https://github.com/citp/anomalous-tor-keys.git
 97 |
98 | 99 |

100 | The repository also contains our tool itos that we used to identify 101 | onion services that were likely targeted by malicious onion service directories. 102 | Run itos -h for a list of supported options. You can run the tool as 103 | follows: 104 |

105 | 106 | 
107 | cd anomalous-tor-keys/code/itos/
108 | go build itos.go
109 | ./itos -hss onion-services.csv -hsdirs hsdirs.csv
110 |
111 | 112 | 113 |

Data

114 |

115 | We publish the following datasets. Each tarball contains a README.txt file that 116 | explains the respective dataset. 117 |

118 |
    119 |
  • 120 | anomalous-keys.tar.xz (1.3 MiB)
    121 | SHA-256: 563fed39e393d9de803b6f7759c3a1a19f22a35781bd52ad6b583e1bac6eceaf 122 |
    • 123 |
  • 124 | targeted-onion-services.tar.xz (3.6 KiB)
    125 | SHA-256: 9384f3de919dceb00c7f92d01182a5f37fdd4e26c47a5a93bd167cf02212f30c 126 |
    • 127 |
128 | 129 | 130 |

Contact

131 |

132 | We are a team of four researchers from two institutions. Please copy 133 | all of us if you have any questions or remarks. 134 |

135 | 141 | 142 |
143 |

144 | Last update: 2017-12-08 145 |

146 | 147 | 148 | 149 | -------------------------------------------------------------------------------- /web/pdf/Bernstein04.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Bernstein04.pdf -------------------------------------------------------------------------------- /web/pdf/Bernstein2013a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Bernstein2013a.pdf -------------------------------------------------------------------------------- /web/pdf/Biryukov2013a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Biryukov2013a.pdf -------------------------------------------------------------------------------- /web/pdf/Boneh1999a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Boneh1999a.pdf -------------------------------------------------------------------------------- /web/pdf/Coppersmith1996a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Coppersmith1996a.pdf -------------------------------------------------------------------------------- /web/pdf/Coppersmith1997a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Coppersmith1997a.pdf -------------------------------------------------------------------------------- /web/pdf/Goldberg2013a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Goldberg2013a.pdf -------------------------------------------------------------------------------- /web/pdf/Hastings2016a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Hastings2016a.pdf -------------------------------------------------------------------------------- /web/pdf/Heninger2012a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Heninger2012a.pdf -------------------------------------------------------------------------------- /web/pdf/Jansen2012a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Jansen2012a.pdf -------------------------------------------------------------------------------- /web/pdf/Lenstra2012a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Lenstra2012a.pdf -------------------------------------------------------------------------------- /web/pdf/Matic2015a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Matic2015a.pdf -------------------------------------------------------------------------------- /web/pdf/Valenta2016a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Valenta2016a.pdf -------------------------------------------------------------------------------- /web/pdf/Winter2016a.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/Winter2016a.pdf -------------------------------------------------------------------------------- /web/pdf/anomalous-tor-keys.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/anomalous-tor-keys.pdf -------------------------------------------------------------------------------- /web/pdf/rivest1978.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/citp/anomalous-tor-keys/b09424f5a21b59fd4605d95ee9d0cc01d81a501b/web/pdf/rivest1978.pdf --------------------------------------------------------------------------------