July 2018 - cypherpunks-legacy

NSA killed system that sifted phone data legally
by h_bray＠globe.com 06 Jul '18

06 Jul '18

http://www.baltimoresun.com/news/nationworld/bal- nsa517,0,5970724.story?page=1&coll=bal-home-headlines Excerpt: The National Security Agency developed a pilot program in the late 1990s that would have enabled it to gather and analyze massive amounts of communications data without running afoul of privacy laws. But after the Sept. 11 attacks, it shelved the project -- not because it failed to work -- but because of bureaucratic infighting and a sudden White House expansion of the agency's surveillance powers, according to several intelligence officials. The agency opted instead to adopt only one component of the program, which produced a far less capable and rigorous program. It remains the backbone of the NSA's warrantless surveillance efforts, tracking domestic and overseas communications from a vast databank of information, and monitoring selected calls.... In what intelligence experts describe as rigorous testing of ThinThread in 1998, the project succeeded at each task with high marks. For example, its ability to sort through massive amounts of data to find threat-related communications far surpassed the existing system, sources said. It also was able to rapidly separate and encrypt U.S.-related communications to ensure privacy. But the NSA, then headed by Air Force Gen. Michael V. Hayden, opted against both of those tools, as well as the feature that monitored potential abuse of the records. Only the data analysis facet of the program survived and became the basis for the warrantless surveillance program. The decision, which one official attributed to "turf protection and empire building," has undermined the agency's ability to zero in on potential threats, sources say. In the wake of revelations about the agency's wide gathering of U.S. phone records, they add, ThinThread could have provided a simple solution to privacy concerns. Hiawatha Bray ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] NSA killed system that sifted phone data legally
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[drone-list] NYT on "The Moral Case for Drones"
by Gregory Foster 06 Jul '18

06 Jul '18

NYT (Jul 14) - "The Moral Case for Drones" by @ScottShaneNYT<http://twitter.com/ScottShaneNYT>: http://www.nytimes.com/2012/07/15/sunday-review/the-moral-case-for-drones.h… I'd like to add a corollary to Godwin's law<http://en.wikipedia.org/wiki/Godwin%27s_law>: any sufficiently long conversation about "smart weapons" will witness invocation of the firebombing of Dresden. gf -- Gregory Foster || gfoster(a)entersection.org<mailto:gfoster@entersection.org> @gregoryfoster <> http://entersection.com/ _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [drone-list] NYT on "The Moral Case for Drones"
by Knuckey, Sarah 06 Jul '18

06 Jul '18

Here is one response to the Scott Shane piece, written by Jeremy Hammond: http://www.foreignpolicyjournal.com/2012/07/16/the-immoral-case-for-drones/

1 0

[drone-list] US DoD Directive on Autonomy
by Gregory Foster 06 Jul '18

06 Jul '18

Secrecy News (Nov 26) - "Autonomy in Weapon Systems": http://www.fas.org/blog/secrecy/2012/11/weapons_autonomy.html One note. Mention is made in this document about the importance of "verification and validation" (V&V) of systems. Earlier this month, DARPA's High-Assurance Cyber Military Systems (HACMS) program awarded a 4.5 year $18M contract to an international consortium "to develop a complete, formally proven architecture to protect the control and communication systems of an aerial vehicle from compromise by faults and targeted attacks." http://www.nicta.com.au/media/current/nicta_to_develop_critical_software_fo… Part of that award went to National ICT Australia [ @NICTA ] which toots its own horn for formally verifying 7,500 lines of C code. That tells you something about the challenge of "formal verification" which mathematically proves a system will behave as specified - a much higher bar than "rigorous" testing. http://en.wikipedia.org/wiki/Formal_verification That also tells you something about the complexity of systems which have thus far achieved formal verification. For comparison, the Linux kernel---which sits at the heart of many of the workstations used by the US military's remote pilots---surpassed 15 million lines of code in January, leading the creator of Linux, Linus Torvalds, to lament that he is "afraid of the day" when there will be an error that "cannot be evaluated anymore." http://www.tomshardware.com/news/Linux-Linus-Torvalds-kernel-too-complex-co… Considering DARPA knows the path to formal verification of larger systems must be cleared - demand it. The challenge of formal verification presents a strong argument for delaying deployment of lethal autonomous systems. gf -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [Freedombox-discuss] Thoughts on MAC Addresses
by John Gilmore 06 Jul '18

06 Jul '18

It is worthwhile considering the privacy implications of MAC addresses. Here's some info. * MAC addresses on Ethernet gear come in two parts: the company ID number, and the manufacturer-assigned extension number. The company ID reveals who built the Ethernet gear; the extension number is similar to a serial number. So, a database of MAC addresses can be used to find equipment made by particular manufacturers, for example if you know a vulnerability in that product as shipped and want to exploit it; or if you are a malevolent government intending to confiscate all hardware that's likely to be running FreedomBox software. * Apple iPhones record the MAC addresses that are nearby, report these to Apple, and Apple uses them to return a physical position fix. This is used to more rapidly cause the GPS algorithm to converge on a position, and also used when GPS isn't working. The phones often report their GPS position and any nearby MAC addresses back to Apple servers. (Apple formerly used startup Skyhook Wireless for this service, but ended up disintermediating them by covertly using their customers' iPhones to collect an equivalent database.) See: https://en.wikipedia.org/wiki/Skyhook_Wireless It's easy for hackers to query that database of MAC addresses and locations, by pretending to be an iPhone seeking its location. * Google Street View vehicles recorded the MAC addresses of all accessible WiFi access points that they passed. Google then used this database to guess at the physical location of Android mobile phones who can also hear beacons from the same MAC addreses. Android phones may now be doing what iPhones do, reporting nearby MAC addresses plus the phone's GPS location to a Google server. * By default, every IPv6 interface's MAC address is in the low order bits of its IPv6 address. See RFC 4291 (IPv6 Addressing Architecture) Section 2.5.1 and Appendix A; RFC 2464 (Transmission of IPv6 Packets over Ethernet Networks); RFC 4862 (IPv6 Stateless Address Autoconfiguration); RFC 4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6). So, anyone who ever communicates with a machine via IPv6 will generally learn the MAC address of one of its interfaces, unless that machine specifically uses the RFC 4941 privacy extensions to generate a temporary random address and change it periodically. (In Linux, the default is to not use such temporary addresses; you can change that default by writing 1 to /proc/sys/net/ipv6/conf/default/use_tempaddr. You can change it for all current devices by writing to /proc/sys/net/ipv6/conf/all/use_tempaddr. If you want privacy, it's probably good to write a 1 to both.) * If someone who is in radio range of a WiFi access point can send it packets that cause it to communicate over the Internet, that someone can figure out the correlation between the access point's MAC address and the IP address (v4 or v6) it uses over the Internet. For example, connecting to the access point and then sending a DNS query for your own domain, will cause a DNS query packet to be forwarded to your own domain server, from the global IP address of the access point. Your domain server can then log that packet and correlate it with the access point's MAC address seen by the wireless device that generated it. Many closed access points handle DNS packets even before authentication, since they rely on Web page spoofing to force people to "log in" or "check a box to agree to terms". It's even simpler if the access point is open. If a police car crusing past a FreedomBox can cause it to access a police Internet DNS site, they can map the MAC address to the IP address of that FreedomBox. So, there are two aspects of MAC addresses that are problematic: that they are long-term identifiers, and that they actually reveal things about that device. If upon installation the FreedomBox software merely changed each machine's MAC address to a random value, we'd solve the second problem (avoid revealing who made the device). However it's trickier than that, since we may not have a good source of randomness at installation time (making our addresses too predictable), and also, devices that have a random MAC address (instead of one assigned to a company on the IEEE-maintained registry of Ethernet manufacturers) might make it too obvious that the manufacturer's MAC address had been overwritten, which would lead totalitarians to pay more attention. We could carefully pick a random number and then package it into a MAC address that looks like it comes from a popular manufacturer. For example, we could have a table of a hundred big manufacturers, and for each, the known range of "serial number" bits that they shipped. We'd use part of our random number to pick a manufacturer, and another part to pick a valid-looking serial number within that manufacturer's products. To avoid drawing scrutiny, we might have to be more selective, e.g. avoid putting a MAC address from a 10-megabit 1990s 3Com Ethernet card onto a 2010s WiFi link. Changing the MAC address to a packaged random value *periodically* -- perhaps daily or weekly -- would solve the first problem of its being a long-term identifier. IPv6 can cope with that without trouble; it encourages interfaces to have multiple IPv6 addresses, deprecating old ones while allowing existing communications to work. IPv4 can also cope with changed MAC addresses; within seconds, any neighbor on the Ethernet or radio who is communicating with the node will know the new MAC address that matches the same old IPv4 address. We would have to test any new candidate MAC address, before using it, by trying to communicate with it and seeing if anything responds. See the "Duplicate Address Detection" algorithm in RFC 4862. > *If* preventing people from being identified by MAC addresses should be > a goal, how do we accomplish that? The MAC address can, but shouldn't > be set in the firmware, we can't change it or set it, from the running > system, there. That's good, because it means the bootloader can't be > changed on a running system. MAC addresses in all modern networking chips can be set from software. I think what you mean is that the *default* MAC address is stored in flash, near where the boot firmware is stored, and that some boards running Linux can't rewrite that flash memory. "Can't" is probably too strong a word -- many can, but how to do so is often merely undocumented, providing a little security-by-obscurity. > So, where can we set the MAC address? The obvious solution is to put it > into /etc/networking/interfaces, but that'll harm folks who want some > form of anonymity. We can use 0:0:0:0:0:0 as a default MAC address in > /etc/networking/interfaces and folks who want to set a static one can > edit the file to set it there, while folks who want to use a MAC changer > can run a service hooked through Plinth. "ifconfig DEV hwaddr xx:xx:xx:xx:xx:xx" or "ip link set DEV xx:xx:xx:xx:xx:xx" lets you set the MAC address of DEV at any time from a shell, as root. There is also an equivalent low level interface. We can't set 0:0:0:0:0:0 as every interface's MAC address. There is good reason to have unique addresses on Ethernet interfaces. On a given Ethernet, or in a given WiFi radio range, communication will fail if multiple interfaces have the same address (unless those interfaces specifically coordinate with each other, e.g. are plugged into the same node and use custom software to pretend to be a single interface). If you and your neighbor both have a FreedomBox with WiFi address 0:0:0:0:0:0, there will be no way to send a packet to YOUR FreedomBox; your neighbor's box will also receive the packet and is just as likely to respond to it -- which will confuse the communication when BOTH boxes respond to it. John _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

None
by Jim Choate 06 Jul '18

06 Jul '18

> > Socialism: state intervention in private transactions. By extension, any > > state is socialist, or it's not really a state, but a company in the defense > > (and maybe law) business. > > The problem here is there isn't any issue of 'private property' so there > can't be any 'private transactions' in a socialism. This description is > more applicable to fascism. Private transaction = transaction between two individuals / companies who are both not employees / property of the state (not even partially). The point being that I don't care if the gov't stops Clinton from selling his daughter to someone else - he's a state employee. Mark

1 0

None
by Jim Choate 06 Jul '18

06 Jul '18

> > Socialism: state intervention in private transactions. By extension, any > > state is socialist, or it's not really a state, but a company in the defense > > (and maybe law) business. > > The problem here is there isn't any issue of 'private property' so there > can't be any 'private transactions' in a socialism. This description is > more applicable to fascism. Private transaction = transaction between two individuals / companies who are both not employees / property of the state (not even partially). The point being that I don't care if the gov't stops Clinton from selling his daughter to someone else - he's a state employee. Mark

1 0

None
by Jim Choate 06 Jul '18

06 Jul '18

> > Socialism: state intervention in private transactions. By extension, any > > state is socialist, or it's not really a state, but a company in the defense > > (and maybe law) business. > > The problem here is there isn't any issue of 'private property' so there > can't be any 'private transactions' in a socialism. This description is > more applicable to fascism. Private transaction = transaction between two individuals / companies who are both not employees / property of the state (not even partially). The point being that I don't care if the gov't stops Clinton from selling his daughter to someone else - he's a state employee. Mark

1 0

None
by Jim Choate 06 Jul '18

06 Jul '18

> > Socialism: state intervention in private transactions. By extension, any > > state is socialist, or it's not really a state, but a company in the defense > > (and maybe law) business. > > The problem here is there isn't any issue of 'private property' so there > can't be any 'private transactions' in a socialism. This description is > more applicable to fascism. Private transaction = transaction between two individuals / companies who are both not employees / property of the state (not even partially). The point being that I don't care if the gov't stops Clinton from selling his daughter to someone else - he's a state employee. Mark

1 0