Archive for the ‘security’ Category.

Lead the Charge Against More Advanced APIs

I received a conference solicitation with the provocative title of “Lead the Charge Against More Advanced APIs”. You could register and:

Add to your skills to defend against genuinely advanced cyber attackers employing a myriad of methods such as DDoS, DNS and API … Gain tools and insights that can help you protect enterprises from more advanced APIs

I suppose that I should be kind and refrain from making fun of the copywriter. On the other hand, I really hope that this imprecision is not catching.

Hint to future copywriters on security topics: DNS is a service, APIs are interfaces, they can be attacked, they are not attacks or attack methods.

Smart endpoints, complaint aggregators, carrier support, and real-time interfaces for law enforcement: A solution for the 2013 FTC Robocall Challenge

Submitted to the FTC Robocall Challenge on January 15, 2013 [link]

Overview

I propose a system comprised of smart endpoints and complaint aggregators, with interfaces to carriers and law enforcement, partially supported by bounties from successful prosecutions.

Benefits from this system accrue to all parties:

  • Smart endpoint hardware and software near consumers provides call screening features in a simple comprehensible manner (from the consumer point-of-view, an answering machine plus screening features). Building in flexibility allows the system to remain nimble as techniques become more sophisticated. Smart endpoints can capture complete audio data, compute audio fingerprints, and make classification decisions based on both content and metadata.
  • Complaint aggregation services benefit from a stream of prompt data in high volume. Beneficiaries of that aggregated data include law enforcement personnel and prosecutors, who can prioritize investigations by volume, and build stronger cases with high incident counts that are well-documented, supporting higher fines from successful prosecutions.
  • Interfaces between endpoints, carriers, and complaint aggregators enable the use of live call transfers as one of the call rejection mechanisms. Benefits include improved opportunities for call tracing, and selective automation-supported transfer of calls to law enforcement for identifying qualifiers and telemarketers.
  • Financial incentives from sharing bounties on successful prosecutions give at least a psychological/marketing boost to the entire system. There is some history for bounties in the U.S, in the form of qui tam litigation. Naming the endpoints “privateers” and noting the history of letters of marque is one evocative way to market the concept to consumers. Who doesn’t want to own a privateer protecting their privacy?

Details

The consumer point of view

The smart endpoint is easily comprehended as an answering machine PLUS:

  • Easy call block (one-press blacklist) and call enable (whitelist)
    • Implementation: Blacklist with simple sequence such as “*#” or long-press-* or long-press-#. Whitelist via memory of outbound calls. The typical set of answering machine features is also provided.
  • Automatic screening and classification into ring-through or take-a-message with automatic classification into an inbox or a suspicious box.
  • Like the current generation of call screening, some use of Caller ID is not ruled out, though clearly it is not definitive for robocall identification. Mainly Caller ID may be useful for classification of legal unwanted calls, since legal callers have no need to hide their source. Legal callees have every right to ignore high-volume unwanted calls despite their illegality. Even forged Called ID data may be useful as weak evidence if callers exhibit any predictable geographic or bogus forgery preferences.
  • Take-a-message behavior includes a CAPTCHA to add one more bit of evidence. I assert that “dial 23 to leave a message” is barely distinguishable from “leave a message after the tone” in annoyance level. (A minor disagreement with Mr Schulzrinne’s seminar presentation on “The Network”.)
  • Easy after-the-fact blocking (manual classification) while listening to recorded messages
  • Handles all unwanted calls: illegal robocalls or unwanted legal calls (Note: This is my definition of optimum behavior — the consumer gets to define “unwanted”.)
  • Low probability of false positives since CAPTCHA can take a message and mark it less-suspicious
  • Incentives: reporting incidents offers consumers:
    • Valuable prizes: opportunity for share of proceeds from prosecution
    • satisfaction of getting a caller blocked on your friends’ phones
    • know that the reports of others are contributing to the quality of your classifier

Behind the scenes, this endpoint can:

  • Send unwanted call data (recorded audio and/or acoustic fingerprints, caller ID) to complaint aggregator
  • Use crowdsourced collaborative filtering data from complaint aggregator to improve classification
    • pre-filing
    • post-filing
  • Transfer live calls (classified as unwanted) via carrier for live call tracing or human investigation, while passing incident and classification information out-of-band to the complaint aggregator so it can be shared immediately with cooperating law enforcement systems.

The system point of view

Complaint Aggregators can:

  • Collect high-quality unwanted call data, including:
    • recorded audio and/or derived data such as acoustic fingerprints, speech to text, or vocoder-based respresentations
    • evidence from CAPTCHA success/failure
    • evidence from human consumer’s manual classification
  • Offer to share valuable prizes when aggregated evidence contributes to prosecutions.

Carriers can:

  • Provide support for transferred calls from consumer endpoints, for live call tracing, or for transfer to live law enforcement investigators so qualifiers and telemarketers can be identified.
    • Implementation: Like current carrier switches that support call transfer via flash-dialcode-phonenumber, carriers could also support call transfers with an opaque incident number included in the dialing sequence. The opaque incident number could be passed to the destination as DNIS (dialed number) information, and this small datum could be a (aggregator#,incident#) key that would allow systems with access to aggregator data to immediately look up incident data (which was transmitted to aggregators out of band).
  • Offer the consumer endpoint features as a hosted IVR service instead of customer premise equipment

The law enforcement and prosecutor point of view

Complaint aggregators provide a high-quality stream of evidence:

  • verifiable audio recordings
  • automatic prompt high-volume clustering of identical robocall messages

Carrier forwarding of live calls includes:

  • opportunity for more information from network tracing of live calls,
  • opportunity for insertion of human investigators into robocall-initiated calls to collect information from qualifiers and telemarketers
    • automatic clustering based on initial robocall message provides opportunity to prioritize high-volume known offenders for live call transfer to human investigators

Therefore law enforcement is more likely to identify the actual source of illegal calls, and prosecutors have a strong record of high volume incidents supporting a case for high fines.

Interfaces among providers of these components and services are important

Smart endpoints and complaint aggregator services would be likely to be tightly integrated, as rapid nimble new feature development is important, so single-vendor suppliers of both would benefit from coordination between endpoint features and back-end database and computation features. But a competitive market including multiple endpoint/aggregator providers would be more healthy than a single source. Each supplier could implement a closed proprietary system and could innovate as rapidly as they want.

Law enforcement systems and personnel would want a common interface to multiple complaint aggregators and multiple carriers. Some simple general interfaces for pulling evidence from aggregators and carriers in real time would limit implementation on the law enforcement side without slowing down the innovation the data collection side.

Discussion of hostile counter-measures

Indeed, illegal callers are likely to adopt some counter-measures, some of which will be more effective than others. All will increase the expenses incurred by the callers.

  • To evade CAPTCHA challenges, callers may implement voice recognition or insert humans. Both are expensive, and can be made more so by increasing the variety of challenges.
  • To evade content matching, callers can introduce chaff to recording content (noise, distortion, voice generator parameter changes, music, timing changes). Audio fingerprinting techniques are already immune to many of these variations. Since the real domain is speech, text to speech algorithms will tend to be insensitive to these recorded content changes as well.
  • Attackers could try to overwhelm or subvert aggregator services or data structures. However, participation in the infrastructure would be limited to subscribing users, with enough resiliance to restrict access to legitimate devices and ignore denial of service attacks.

Evaluation

At a minimum, even as a standalone device, a smart endpoint offers as much as current user-configured call screening devices, with a simple comprehensible consumer feature set.

Aggregating evidence from many endpoints implementing manual classification and automatic CAPTCHA (in collaborative filtering and crowdsourcing fashion) makes the endpoints more powerful than any standalone device.

Access to realtime streams of call information through aggregators allows law enforcement to move from correlating randomly sampled incomplete delayed complaint reports to acting on deliberately selected fully-documented immediate events. Then for prosecution, automation support for building large related incident lists are useful for maximizing fines.

Endpoint implementation can be in a hardware device near the consumer, or can be a hosted service located at a carrier or IVR vendor, or can be embedded in a mobile phone application. All of those implementations benefit from sharing data with aggregators.

For the future, an architecture including both distributed smart endpoints and centralized database and compute support is a natural solution to implementing new technologies, such as authenticated caller ID in a VoIP-based consumer world. Successful endpoint implementors and complaint aggregators in the current generation will be well positioned to deliver implementations and services for the next generation.

CA certificate forged via MD5 collision

Security researchers successfully forge a CA certificate, allowing them to produce new certificates that will be trusted by every browser:

MD5 considered harmful today
Creating a rogue CA certificate
Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 “collision”. Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

Now that it’s been demonstrated once, it won’t be long before someone malevolent does it too. One hopes that, by then, software desupporting MD5-based signatures will have been widely distributed, and certificates containing them will have been retired.

Update: Of course, the day of doom can be postponed by getting every MD5-cert-issuing CA to immediately update their software to: (a) stop issuing MD5-based hashes, or, at least, (b) make their certificate serial numbers less predictable. The latter is a fairly small change. Is it too much to hope for?

Program verification is not a silver bullet

Alan Shostack points out that
Alan Drexler is excited about the interesting AMS survey article
“Formal Proof” (Hales)
because of the prospects for program verification.

I think the article is better at inspiring hope about computer verification of proofs than about proof system verification of computers.

For balance one should read the still-persuasive May 1979 paper
“Social processes and proofs of theorems and programs” (De Millo, Lipton, Perlis).
The abstract:

It is argued that formal verifications of programs, no matter how obtained, will not play the same key role in the development of computer science and software engineering as proofs do in mathematics. Furthermore the absence of continuity, the inevitability of change, and the complexity of specification of significantly many real programs make the formal verification process difficult to justify and manage. It is felt that ease of formal verification should not dominate program language design.

(Note that that there are lots of copies cached around the web if you don’t have an ACM Portal subscription.)

MITM on jury duty

Yesterday I reported to my local Hall of Justice for jury duty.

They offer free wireless for jurors waiting to be called into the court. In the vicinity was the state-run access point, and a host-to-host wireless network calling itself “Free Internet Service”.

What could that be but a man-in-the-middle attacker interested in packet capture? It could have been one of the other jurors. Or a box somebody placed deliberately close to the known public access point.

Due to security fatigue I didn’t even try to gather any information on the rogue. Now my conscience is catching up to me, telling me I should at least tell the Hall of Justice folks, in case this MITM is a permanent installation.

2007 Rochester Security Summit

I’ve been helping to organize a regional security conference, the second annual Rochester Security Summit, scheduled for October 3 and 4. Good presenters, both business and technical tracks. Some seats are still open, register now!

Vote but Verify

Local Rochester-area political blogger Thomas Belknap recently railed about HR 811, interpreting its requirement of a voter-verified durable paper ballot as a small-minded banning of an attractive future of modern networked reliable electronic voting machines. I could not resist posting my disagreement into the comments on his blog, and perhaps I am going to convince him, as he edited out my most provocative snide political shots and left in some of my more reasoned comments.

As a security person, I must point out that if machines do not produce a reliable auditable record, then all you have is a fait accompli fraud-blessing device. That’s the short version of the security argument.

I’m willing to go along with NIST that, as of today, all-electronic systems are an important research topic, not a settled present alternative:

The approach to software-independence used in op scan is based on voter-verified paper records, but some all-electronic paperless approaches have been proposed. It is a research topic currently as to whether software independence may be able to be accomplished via systems that would produce an all-electronic voter-verified, independent audit trail (known as software IV systems).

A durable paper ballot requirement is not a retrograde goof, nor a rejection of e-voting. It’s a reflection of current reality, that all-electronic e-voting implementations are asking for trouble. Codifying an allowance for all-electronic systems today would just open the door to arguments about what’s good enough cryptographically, arguments that will be settled by folks even less competent than our representatives. Codifying the well-understood voter-verified paper audit trail as a requirement puts an immediate crimp in the shopping spree for fancy-looking machines that are rotten inside – a shopping spree that will continue if this law isn’t passed, creating an ever-larger lump of sunk investment in pretty bad technology.

A paper audit trail today isn’t a rejection of e-voting, it is progress toward a more robust implementation that in the future will, no doubt, also include other alternative durable auditable records.

For credible background on the security geek consensus, see the above-quoted NIST draft, the US ACM policy recommendation, or Bruce Schneier (University of Rochester physics alumnus!). Or anything by Ed Felten or Avi Rubin on this subject. In this case, our representatives seem to be listening to informed advisers.

Regarding politics: All parties’ oxes have been gored at one time or another by voting fraud or rumors of fraud, so this does seem like an issue on which a consensus could form.

Goodbye IE6

My installation of Microsoft Internet Explorer 6 (version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519) has developed the unfortunate problem of frequently (about once a day) trashing its ability to render correctly: painting its window contents at various places all over the display, rendering in the wrong font, leaving turds all over its window while scrolling. Once it starts I have to kill iexplore.exe to make it stop. I believe it is fully-patched.

In my mind the appearance of this problem is correlated with the appearance of two new aggressive JavaScript interfaces: The much-improved BlogLines feed selector, and the very-irritating Yahoo Finance streaming quotes feature (which slows down every refresh even when set to “off”). That may just be coincidence.

It does mean there’s some serious undiscovered memory corruption going inside IE6 somewhere.

It’s a good time to switch to FireFox and/or IE7.

Yahoo’s Browser-Based Authentication service

Yahoo’s release of open access to its BBAuth authentication service (see also here and here) is a big step forward. It’s just the thing for many simple applications. It’s not as good as a user-controlled cross-provider identity scheme, but the emergence of a few real high-volume competing web services will help drive us there.

NY STAR: An accident waiting to happen

The New York State School Tax Relief (STAR) program is an identity theft “accident” waiting to happen. Homeowners apply for property exemptions on their primary residence, and file with their local tax assessors. (In the first year or so of this program, total chaos ensued in assessor’s offices all over the state.) Extra tax exemptions for senior citizens are means-tested, and require homeowners to submit their SSN or a copy of their income tax returns to the local assessor.

  • In New York City, they want SSNs from everybody. Just because it’s authorized by law (in the NYC Administrative Code) doesn’t mean it’s a good idea. Everywhere else, they’re only collecting SSNs or income tax returns from low-income seniors.
  • It’s hard to justify leaving so much personal financial information sloshing around assessor’s offices all over the state. And which is worse: copies of tax returns in piles in sleepy small-town assessor’s messy offices, or huge indifferent big-city assessor’s chaotic offices? Need to know? Mind your own business.
  • As their normal traffic is public information, assessors are not necessarily tuned to protecting private personal information. For a recent example of a public record agency handling private data, see the story of how the Suffolk County (NY) clerk’s normal processes put a few thousand SSN’s in the public record [via Emergent Chaos].
  • Perhaps all these violations of “don’t ask for information you don’t need” and “don’t store information you don’t need again” were less serious even a few years ago, but the consequences of these old ways are getting worse every day.
  • Though it’s hard to patch the process perfectly, one simple fix would be to direct the flow of sensitive information away from local offices, e.g. create a state tax return checkoff that allows the income tax people to inform the assessors about eligibility and primary residence status without revealing any income information.
  • Well, the politics is irritating too. Creating yet another “take with one hand, give back with another” program is inefficient, and clearly its primary purpose is to create an opportunity for attaching a politician’s name to a tax cut, with extra discrimination making the program harder to kill.

Update 3/7/2006 see also: The public servants at the Ohio secretary of state insist on treating documents that pass through their hands as public despite embedded SSNs.

Update 4/11/2006 see also: Broward County (FL).