Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"evil twin" certificates can invalidate valid objects #29

Open
dseomn opened this issue Nov 10, 2015 · 0 comments
Open

"evil twin" certificates can invalidate valid objects #29

dseomn opened this issue Nov 10, 2015 · 0 comments

Comments

@dseomn
Copy link
Member

dseomn commented Nov 10, 2015

RPKI objects can have multiple parents in a few cases. This should be supported such that if any path to a trust anchor is valid, the object is considered valid.

In an "evil twin" attack, a malicious CA tweaks, re-signs, and publishes another CA's certificate. The re-signed copy appears to be a parent of the victim CA's children: the issuer, AKI, etc. in the victim CA's children match the subject, SKI, etc. of the re-signed CA cert. However, one or both of the following will be true of the re-signed copy if it is an "evil twin" CA certificate:

  • the evil twin certificate is invalid (e.g., it claims RFC3779 resources that are not held by the malicious CA that signed it), or
  • the victim CA's children appear to be invalid when checked against the evil twin (e.g., because the children use resources outside the modified resources in the evil twin).

If a relying party only attempts to validate the victim CA's children via the evil twin, the RP will incorrectly consider the children to be invalid.

Certain circumstances can cause RPSTIR to only attempt to validate an object via an evil twin, which makes it possible for an attacker to effectively invalidate another party's objects.

Reported by: rhansen

Original Ticket: rpstir/tickets/29

rhansen added a commit to rhansen/rpstir that referenced this issue Jan 18, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
rhansen added a commit to rhansen/rpstir that referenced this issue Feb 18, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
rhansen added a commit to rhansen/rpstir that referenced this issue Feb 18, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
@rhansen rhansen added the bug label Feb 19, 2016
rhansen added a commit to rhansen/rpstir that referenced this issue Feb 20, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
rhansen added a commit to rhansen/rpstir that referenced this issue Feb 24, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
rhansen added a commit to rhansen/rpstir that referenced this issue Feb 26, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
rhansen added a commit to rhansen/rpstir that referenced this issue Apr 22, 2016
Construct some simple RPKI hierarchies and try every possible object
insertion order to see if it's possible for a valid object with an
evil parent to ever be considered invalid.

addresses [bgpsecurity#29]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants