[cryptography] No proof.
On 23/09/13 02:07 AM, Shawn Wilson wrote: Again some proof would be nice. No proof. Don't forget who you are dealing with. We have to suspend normal degrees of skepticism and work with reasonable judgement, "balance of probabilities." The NIST/RSA breach event exceeds by a country mile the balance of probabilities. You'll never get NSA to say "darn, fair is fair, you got us! grin!" On the other hand, they will run around everywhere and say "you've got no proof..." iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Deleting data on a flash?
On 23/09/13 07:12 AM, Dev Random wrote: I've been thinking about this for a while now and I don't see a way to do this with today's mobile devices without some external help. The issue is that it's pretty much impossible to delete data securely from a flash device. Why is that? That means that in order to guarantee PFS, you have to store the keys in memory only. But again, in a mobile environment, you don't have access to stable memory either, because of the OS restarting your app, or the device itself rebooting. Let's call this the persistence/deletion issue. So, I submit that PFS in async messaging is impossible without help from some kind of ephemeral, yet persistent storage. A possible solution might be to store a portion of the key material (through Shamir's secret sharing) on servers that you partially trust. (I agree with the difficulty in general. Stating anything like PFS in the context of a protocol makes less sense if one considers that the clients either end save the messages.) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Deleting data on a flash?
On Mon, Sep 23, 2013 at 11:02:45AM +0300, ianG wrote: > On 23/09/13 07:12 AM, Dev Random wrote: > >I've been thinking about this for a while now and I don't see a way to > >do this with today's mobile devices without some external help. > > > >The issue is that it's pretty much impossible to delete data securely > >from a flash device. > > Why is that? I presume it's due to extra blocks due to overprovisioning. There is no way to verify the block you've zeroed or randomized has been really overwritten. It is much easier to destroy the secret of a cryptofs. I've just looked, and there seems to be no easy way to mount an encrypted partition on Android, though GuardianProject has a LUKS howto. signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Deleting data on a flash?
While I get wear leveling is a problem, I'm not sure if the flash in a phone is even going to use wear-leveling, but say for the sake of argument it does. It is however not a completely brand-new problem, relatedly spinning disks now and then suffer sector failures, and the failed sectors are remapped by th drive firmware to another spare good sector. Consequently data that you might have wanted to securely delete could be left still readable by a lower level read. Dm-crypt(*), the hard disk encryption system on linux, offers a solution to the sector remapping problem: a key management system called LUKS (Linux Unified Key Setup). How it works is that the key you woul like to be able to delete is secret shared so that you will need k of n blocks to access the key. This provides also additional redundancy - you dont want a single copy of your access structure in case it suffers a sector failure. To delete simply delete all of the n blocks. So long as < k of the blocks have failed, your data is secure. k is chosen to make that astronomically unlikely (short of a complete disk failure, which you're going to notice). For wear-leveling its more tricky, but it I think the trick to deletion would be to delete and temporarily fill the disk - even wear leveling has to delete then. You probably want the LUKS k of n trick also to account for partial failures and inaccessible spare capacity held for remapping. Also it seems to me that SSD drive manufacturers ought to have a special deletable NVRAM for key storage. Its not exactly an unknown problem, would allow instant secure deletion. Of course people may rightly not trust the manufacturer, but it wouldnt hurt to mix it in (xor the LUKS style key and the NVRAM deletable). Apparently or so I've heard claim SSDs also offer lower level APIs to actually wipe physical (not logically wear-level mapped) cells, to reliably wipe working cells. Anyone know about those? They could be used where available and to the extent they are trusted. Adam (*) DM = Device Mapper, a file system layering mechanism on linux. On Mon, Sep 23, 2013 at 11:02:45AM +0300, ianG wrote: On 23/09/13 07:12 AM, Dev Random wrote: I've been thinking about this for a while now and I don't see a way to do this with today's mobile devices without some external help. The issue is that it's pretty much impossible to delete data securely from a flash device. Why is that? That means that in order to guarantee PFS, you have to store the keys in memory only. But again, in a mobile environment, you don't have access to stable memory either, because of the OS restarting your app, or the device itself rebooting. Let's call this the persistence/deletion issue. So, I submit that PFS in async messaging is impossible without help from some kind of ephemeral, yet persistent storage. A possible solution might be to store a portion of the key material (through Shamir's secret sharing) on servers that you partially trust. (I agree with the difficulty in general. Stating anything like PFS in the context of a protocol makes less sense if one considers that the clients either end save the messages.) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Deleting data on a flash?
On 09/23/2013 10:02 AM, ianG wrote: >> The issue is that it's pretty much impossible to delete data securely >> from a flash device. > Why is that? The flash memory controller hides the real storage cells from you and spreads writes across all cells equally for wear-leveling. You cannot directly access the cells. Some SSDs have a secure erase option, but you never know if it is properly implemented, and you can only use it to wipe the complete drive. https://www.schneier.com/blog/archives/2011/03/erasing_data_fr.html [...] Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs. --Mo ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Deleting data on a flash?
Adam Back writes: >Apparently or so I've heard claim SSDs also offer lower level APIs to >actually wipe physical (not logically wear-level mapped) cells, to reliably >wipe working cells. Anyone know about those? They could be used where >available and to the extent they are trusted. What you're asking is "is there a way to bypass the FTL (flash translation layer) on SSD's"? The answer is "it depends", it's going to be manufacturer/vendor-specific and you'd need a very deep knowledge of the internals of the FTL and the layout formats it uses to make use of the capability. If you just want a blank "erase everything" then that's already present as the ATA Secure Erase command, you just need to find an SSD that gets it right, i.e. that does actually erase all flash when you send it the command and that doesn't brick itself in the process (see e.g. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase). Or you can get one of the notoriously flaky SSD models like the Intel 320 and just wait for your data to go away all by itself. (That would make for an interesting plausible-deniability defence, "yes of course all the data's gone, look at the model number of the SSD"). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Trevor and Adam for your comments on this - I take your point about the importance of forward secrecy for metadata, so I'll abandon the idea of using ephemeral-static ECDH to protect the metadata. On 20/09/13 01:55, Trevor Perrin wrote: > Interesting, are the codes passwords? Short Auth Strings? Each endpoint generates a random code (19 bits, represented as 6 decimal digits). The users exchange codes verbally, and the endpoints use the two codes to find each other and obfuscate the key agreement. The meaning of "find each other" depends on the communication channel; in the case of Bluetooth, the endpoints use the codes to generate a Bluetooth service UUID; each endpoint advertises a service with that UUID, looks for nearby devices advertising that UUID, and makes an unpaired RFCOMM connection to any it finds. The key agreement starts with a hash commitment, followed by an exchange of ephemeral ECDH public keys. Two short authentication strings (again, six decimal digits) are derived from the shared secret; the users exchange the authentication codes verbally to complete the process. > (Elligator + DH-EKE makes a nice PAKE, fwiw.) Thanks, I'll look into it. The protocol I described above is (loosely ZRTP-inspired) homebrew, and it would be nice to move to something more standard. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSQCs5AAoJEBEET9GfxSfMLyIH/i1x/yxCsge/QSoYVUhF4tSs xBeEcZkRzsvaOdA97c02cFBQJqThnS5m3af0T6dxZWr5PfNJBnxO8j0T5gSkjgVL lSwHUZG17IGWq9xGY49XTkpO/yw91qjvZhoIuzJf4BSnSV3c37sNIC/4GrXT88TA 2yP80YaWJtiLHFBgFoLkK6qKWyB3asIQ+zxd2AOcPtxT4QoQ8ySksSu3SWT9M8do 08hooVd6uVifHvWHSzBGnPIYGdoxeyUYEBwDWXC/ogMRIBqoAZA+nWtScm+cYqZI um2UIByTRLcE5JOxQHw2IV1FdurBIH/zZJ2Dsc1CbFhEbhEupPxP6Dl/XZM6VsU= =Otj3 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/09/13 05:12, Dev Random wrote: > I've been thinking about this for a while now and I don't see a way > to do this with today's mobile devices without some external help. > > The issue is that it's pretty much impossible to delete data > securely from a flash device. That means that in order to > guarantee PFS, you have to store the keys in memory only. But > again, in a mobile environment, you don't have access to stable > memory either, because of the OS restarting your app, or the device > itself rebooting. > > Let's call this the persistence/deletion issue. Yes, this is a major issue with current mobile devices. As far as I'm aware, SSD commands like Trim and Secure Erase aren't available on SD cards or the built-in flash storage of mobile devices. Apple came within a whisker of solving the problem in iOS by creating an 'effaceable storage' area within the flash storage, which bypasses block remapping and can be deleted securely. However, iOS only uses the effaceable storage for resetting the entire device (by deleting the key that encrypts the user's filesystem), not for securely deleting individual files. http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf A similar approach would be possible on Android, but I don't know of any Android devices with effaceable storage. The closest I've seen is hardware-backed key storage, where keys are generated, wrapped and deleted by a TPM-like chip. Software can use the TPM to perform operations using the wrapped keys but can't directly access them, and thus they can't be exported from the device without cracking open the TPM (physically or via a vulnerability). http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html In combination with a hardware-based flash controller, this raises the bar for undeleting data pretty high: the adversary must compromise the flash controller to get access to data that's been logically but not physically deleted, then compromise the TPM to unwrap or undelete the deleted key with which the deleted data was encrypted. I'm not saying the bar is too high for a national security agency, but it's too high for some adversaries, so I believe it's worthwhile to think about forward secrecy on current mobile devices. > So, I submit that PFS in async messaging is impossible without help > from some kind of ephemeral, yet persistent storage. A possible > solution might be to store a portion of the key material (through > Shamir's secret sharing) on servers that you partially trust. Sounds like a great idea, especially in combination with a panic button or dead man's switch feature that alerts the servers to delete their shares. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53 UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk= =G1oY -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
I made a suggestion like this elsewhere: Store the keys split up in several different files using Shamir's Secret Sharing Scheme. Encrypt each file with a different key. Encrypt those keys with a master key. XOR each encrypted key with the SHA256 of their respective encrypted files. Put those XORed keys in the headers of their respective files. If you manage to securely wipe just ~100 bits of any of the files, the keys are unrecoverable. I don't know if that can provide enough assurance of secure deletion on a flash memory, but it's better than nothing. Den 23 sep 2013 14:40 skrev "Michael Rogers" : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 23/09/13 05:12, Dev Random wrote: > > I've been thinking about this for a while now and I don't see a way > > to do this with today's mobile devices without some external help. > > > > The issue is that it's pretty much impossible to delete data > > securely from a flash device. That means that in order to > > guarantee PFS, you have to store the keys in memory only. But > > again, in a mobile environment, you don't have access to stable > > memory either, because of the OS restarting your app, or the device > > itself rebooting. > > > > Let's call this the persistence/deletion issue. > > Yes, this is a major issue with current mobile devices. As far as I'm > aware, SSD commands like Trim and Secure Erase aren't available on SD > cards or the built-in flash storage of mobile devices. > > Apple came within a whisker of solving the problem in iOS by creating > an 'effaceable storage' area within the flash storage, which bypasses > block remapping and can be deleted securely. However, iOS only uses > the effaceable storage for resetting the entire device (by deleting > the key that encrypts the user's filesystem), not for securely > deleting individual files. > > > http://web.archive.org/web/20130302170747/http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf > > > http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf > > A similar approach would be possible on Android, but I don't know of > any Android devices with effaceable storage. The closest I've seen is > hardware-backed key storage, where keys are generated, wrapped and > deleted by a TPM-like chip. Software can use the TPM to perform > operations using the wrapped keys but can't directly access them, and > thus they can't be exported from the device without cracking open the > TPM (physically or via a vulnerability). > > > http://nelenkov.blogspot.co.uk/2013/08/credential-storage-enhancements-android-43.html > > In combination with a hardware-based flash controller, this raises the > bar for undeleting data pretty high: the adversary must compromise the > flash controller to get access to data that's been logically but not > physically deleted, then compromise the TPM to unwrap or undelete the > deleted key with which the deleted data was encrypted. > > I'm not saying the bar is too high for a national security agency, but > it's too high for some adversaries, so I believe it's worthwhile to > think about forward secrecy on current mobile devices. > > > So, I submit that PFS in async messaging is impossible without help > > from some kind of ephemeral, yet persistent storage. A possible > > solution might be to store a portion of the key material (through > > Shamir's secret sharing) on servers that you partially trust. > > Sounds like a great idea, especially in combination with a panic > button or dead man's switch feature that alerts the servers to delete > their shares. > > Cheers, > Michael > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJSQDaHAAoJEBEET9GfxSfMw/EH/RQ9nmgB0TfTboQJQThHOD3k > qDD0UrsjHqVwLD4oZu/rFMxIjQv0ECnLh2zJsbR9E0DqEbJAaOQ/GuDcY9RzzZ7S > w1H0Ly1ecJu/iaBQ0Ah0VC+SH0qBWupsk+mSLxeXICMR/6JuMslVYhiErM6mM94O > OLaia9slAoYDSTs+l/fOXXOtzrTTT3Nkn2M9mOhPVe6HAKNi7Ks1qXl/XMe4WZhJ > eTttbqHhkoZDHLnCjKvskwPDUGlcAhNXkZ8sfphWyr77xEOK2md8Okx6oIBzRI53 > UgKiVi3g+VwgY9jxeuUUc8xR6/yYXKncEuSCoF+oVKNsRqBTM7trKh1tU+J3Jqk= > =G1oY > -END PGP SIGNATURE- > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Deleting data on a flash?
On Mon, Sep 23, 2013 at 1:25 AM, Adam Back wrote: > > For wear-leveling its more tricky, but it I think the trick to deletion > would be to delete and temporarily fill the disk - even wear leveling has to > delete then. Reardon et al have some good analysis of this [1,2]. They propose keeping the SSD close to capacity, then periodically filling it to reclaim (thus clear) blocks with remnant data. > Also it seems to me that SSD drive manufacturers ought to have a special > deletable NVRAM for key storage. Its not exactly an unknown problem, would > allow instant secure deletion. TPMs can be used on some systems to store an eraseable key that encrypts other data - Pond is doing this [4]. Also, encrypted flash file systems can (should?) be designed to encrypt data blocks with keys stored in blocks which are copied and cleared periodically. This would achieve good "deletion latency" without having to clear every block of a deleted file [3]. > Apparently or so I've heard claim SSDs also offer lower level APIs to > actually wipe physical (not logically wear-level mapped) cells, to reliably > wipe working cells. Another question is whether SSDs offer low-level APIs to *read* physical blocks. To the extent they don't, forward secrecy is obtainable against a "malware" attacker, even if not against a physical attacker. Trevor [1] http://www.syssec.ethz.ch/people/reardonj/asiaccs12 [2] http://www.syssec.ethz.ch/people/reardonj/sok [3] http://www.syssec.ethz.ch/people/reardonj/usenix2012 [4] https://pond.imperialviolet.org/tech.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] What is Intel(R) Core™ vPro™ Technology Animation
On Sun, Sep 22, 2013 at 9:21 PM, Jeffrey Walton wrote: > ... > Painting with a broad brush, part of the solution is a remote > administration board that can''t be removed. Cf, Fujitsu LOM (Lights > Out Management), HP ILO (Integrated Lights Out) HP RILO (Remote > Integrated Lights Out), Compaq RIB (Remote Insight Board), and Dell > DRAC (Dell Remote Access Card). > > As for who has access, that depends on the quality of the > implementations. > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4784. as an attacker, these are my favorite systems, second only to continuous integration servers. remote access subsystems are hard to upgrade, poorly maintained, and provide exceptional access to hosts and systems. (and in fact, abusing a DRAC to get to the CI to then get keys to the kingdom, is a standard approach once you've got a pivot in network) i cannot count the number of times i've seen insecure configurations deployed, either self signed certs, common passwords, insecure ACLs, or all of the above. i can count the number of times i've seen a properly configured RA system with legit PKI and password management: ZERO! the traditional enterprise network is a soft gooey core with a fig leaf perimeter defense. sad realities... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
(Changing the subject line to reflect topic drift). Thats not bad (make the decryption dependant on accessibility of the entire file) nice as a design idea. But that could be expensive in the sense that any time any block in the file changes, you have to re-encrypt the encryption or, more efficiently the key computed from the hash of the file. Still you have to re-write the header any time there is a block change, and do it atomically or log recoverably ideally. Also you have re-read and hash the whole file to re-compute the xor sha(encrypted-file) header. Well I guess even that is relatively fixable probably eg merkle hash of the blocks of the file instead plus a bit of memory cacheing. Adam On Mon, Sep 23, 2013 at 03:00:03PM +0200, Natanael wrote: I made a suggestion like this elsewhere: Store the keys split up in several different files using Shamir's Secret Sharing Scheme. Encrypt each file with a different key. Encrypt those keys with a master key. XOR each encrypted key with the SHA256 of their respective encrypted files. Put those XORed keys in the headers of their respective files. If you manage to securely wipe just ~100 bits of any of the files, the keys are unrecoverable. I don't know if that can provide enough assurance of secure deletion on a flash memory, but it's better than nothing. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] What is Intel(R) Core™ vPro™ Technology Animation
On Mon, Sep 23, 2013 at 1:33 PM, Jeffrey Walton wrote: > ... > Do you just snatch the source code and intellectual property, or do > you use it as a springboard into other things? (I've never really > thought about it). for better or for worse (mostly better) these systems have made their way into release package builds and production deployment processes. i'm speaking in generalities here, for various reasons, but common trajectories include: - obtaining the private keys or http auth passwords for access to source code repositories. - obtaining ssh private keys for access to other systems, e.g. remote build hosts or even production hosts. - obtaining kerberos/ldap/http/* auth credentials for bug reporting systems, release code signing, or other facilities. - obtaining access to datacenter or operations automation: cfengine, chef, puppet, etc. these are really useful ;) - obtaining test automation tools and other "QA" hooks with elevated access and fewer controls. - privilege escalation on the CI host which in turn is often whitelisted and useful as further pivot. - providing example usage for invocation of and command line parameters for custom internal software. - providing excellent watering hole "infection vector" for technical staff in an org. e.g. taking over engineering workstations. from here you've got everything you need to infiltrate an entire organization. the source code provides "hard coded" keys/passwords or pointers to files where interesting bits lay, the conduit to engineering systems which grant access to public facing services and data stores, the credentials and access for all operational concerns, the org is your oyster... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Attack Driven Defense - infosec rant [was: What is Intel(R) Core™ vPro™ Technology Animation]
i really can't emphasize this enough: robust defense is based on realistic threats, and realistic threats are identified via attackers' perspective. i've been diving down this rabbit hole since before i challenged covert FLTINFOWARCEN members* to "get as blackhat on this motherfucker as you can" during an ad hoc challenge at DEF CON 13. i started down this path when i realized that robust peer to peer systems must protect each node to the highest degree required by any participant. it's the opposite of pandering to the "lowest common denominator". on the plus side, once you have addressed security for the "most stringent requirement" all other systems and peers enjoy the benefit of this elevated level of protection. the bad news is that attacks continue to improve, and i'm no where near satisfied in my ability to protect my own systems against the capabilities myself and my peers have at their disposal. the vast majority of infosec is useless bullshit, the vast majority of infosec conferences are pandering crap; the whole industry (educational/professional/military) is shit, if we're being honest. there is a great talk, fuck you to thinkst.com for blocking it, which covers these failings at just a conference level, with parallels to the industry as a whole: http://207.198.103.187:8081/infosuck-talk_about_talks.pdf sha256: ce836410fdc638066bf6aedec0e1d6f2ce66fb46329c5f92336e42a671272e55 i've never taken an infosec position, for these reasons, among others, and i don't plan to start. quality (and by extension, information security) should be a given, a "built-in" feature of any product, with the investment necessary to achieve it. anything less is bullshit; infosec should not exist! my $0.02 best regards, * hacker friends and i ran a challenge: here's the root password. we're running unencrypted 802.11b wifi, there's a $100 bill in the case. get in - you get money and the hardware! everyone failed, despite two interesting 0day attacks. (we ran IPsec with custom out-of-band keying seeded by VIA C5P hardware entropy generators with our own custom rngd.) after being unable to compromise our setup, $fed handed me a card. i still remember the latin translation adorning his card, which seems particular appropos given revelations this year: "let them hate us, so long as they fear us." On Mon, Sep 23, 2013 at 3:36 PM, coderman wrote: > On Mon, Sep 23, 2013 at 1:33 PM, Jeffrey Walton wrote: >> ... >> Do you just snatch the source code and intellectual property, or do >> you use it as a springboard into other things? (I've never really >> thought about it). > > > for better or for worse (mostly better) these systems have made their > way into release package builds and production deployment processes. > > i'm speaking in generalities here, for various reasons, but common > trajectories include: > - obtaining the private keys or http auth passwords for access to > source code repositories. > - obtaining ssh private keys for access to other systems, e.g. remote > build hosts or even production hosts. > - obtaining kerberos/ldap/http/* auth credentials for bug reporting > systems, release code signing, or other facilities. > - obtaining access to datacenter or operations automation: cfengine, > chef, puppet, etc. these are really useful ;) > - obtaining test automation tools and other "QA" hooks with elevated > access and fewer controls. > - privilege escalation on the CI host which in turn is often > whitelisted and useful as further pivot. > - providing example usage for invocation of and command line > parameters for custom internal software. > - providing excellent watering hole "infection vector" for technical > staff in an org. e.g. taking over engineering workstations. > > > from here you've got everything you need to infiltrate an entire organization. > > the source code provides "hard coded" keys/passwords or pointers to > files where interesting bits lay, > > the conduit to engineering systems which grant access to public facing > services and data stores, > > the credentials and access for all operational concerns, > > the org is your oyster... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] secure deletion on SSDs (Re: Asynchronous forward secrecy encryption)
On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote: Apple came within a whisker of solving the problem in iOS by creating an 'effaceable storage' area within the flash storage, which bypasses block remapping and can be deleted securely. However, iOS only uses the effaceable storage for resetting the entire device (by deleting the key that encrypts the user's filesystem), not for securely deleting individual files. Hmm well thats interesting no? With the ability to securely delete a single key you can probably use that to selectively delete files with an appropriate key management structure. eg without optimizing that, you could have a table of per file keys, encrypted with the master key. To delete a given file you'd re-encrypt everything in the file table to a new key, except the deleted file, and delete, then over-rewrite this "effaceable storage" area. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Attack Driven Defense - infosec rant [was: What is Intel(R) Core™ vPro™ Technology Animation]
On Mon, Sep 23, 2013 at 4:17 PM, coderman wrote: >... >> the source code provides "hard coded" keys/passwords or pointers to >> files where interesting bits lay, someone asks: "how do you find the interesting sources?" this is something i pride myself on, having dealt with scores of large enterprise systems and ERP deployments over many years. i'm going give hints, rather than specifics, but it will be sufficient for the motivated party. (people ask why i rarely distribute code myself - it is because i need every strategic advantage i can get, and custom software, builds, and configurations are part of that operational security. maybe one day...) orienting yourself in a large code base: 0. you must know how to code in, and what frameworks, libraries, and toolkits are common for, the language at hand. 1. filter all the third party components and sources out. these are not interesting. 2. keyword search for password handling, private keys, hardcoded secrets, etc. 3. keyword search for the public interfaces of interest, or API calls exposed, etc. 4. keyword search for business specific terms, e.g. where does the meat of their business logic reside? as you become more familiar with how various institutions implement large systems, you get a "sixth sense" or "intuitive" ability to focus in on the relevant parts and identify where shortcuts and oversights are most likely to occur. rinse, repeat, again and again, and eventually you'll find yourself 10x more effective at these tasks, having combined your increasingly accurate intuition with custom scripts and techniques for maximum effectiveness. it's an almost spooky ability when you look at a piece of code and just "know" where the bugs are, and sure enough, you find them right where you expect. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Mon, Sep 23, 2013 at 4:51 AM, Michael Rogers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thanks Trevor and Adam for your comments on this - I take your point > about the importance of forward secrecy for metadata, so I'll abandon > the idea of using ephemeral-static ECDH to protect the metadata. You could update the "static" ECDH keys used for metadata encryption, so these aren't necessarily exclusive. But since you'll probably need trial decryption for different conversations, I can see why you might prefer more efficient symmetric crypto. Ephemeral-static ECDH is still a nice way to add "sender forward secrecy" though, since compromise of sender private keys wouldn't allow decryption of sent messages. So it could be used with other forward-secrecy techniques. For example, Pond uses an OTR-like "Diffie-Hellman ratchet", but adds an extra ephemeral-static ECDH per message [1]. > The key agreement starts with a hash commitment, followed by an > exchange of ephemeral ECDH public keys. Two short authentication > strings (again, six decimal digits) are derived from the shared > secret; the users exchange the authentication codes verbally to > complete the process. Sounds reasonable but you'll need a 3-way handshake for the short auth strings, which could be awkward in an "asynchronous messaging" scenario. >> (Elligator + DH-EKE makes a nice PAKE, fwiw.) > > Thanks, I'll look into it. The protocol I described above is (loosely > ZRTP-inspired) homebrew, and it would be nice to move to something > more standard. Oh, that's not standard at all, it may even need something weird like a cipher with 256-bit block length... but should be doable [2]. Trevor [1] See "Message encryption" at: https://pond.imperialviolet.org/tech.html [2] See "EKE2" at: http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
