[Ndn-interest] Regarding NDN packet security
Shashank G
shashank.girish007 at gmail.com
Thu Dec 28 21:58:01 PST 2023
Hi,
Thanks for the help, Lixia and Kundan. They helped clarify a lot of things
for me. I however got a few more doubts going through the resources.
1) Suppose a Mal-User floods the PIT with requests for packets that don't
exist, how does the Router prevent itself from being overpopulated with bad
Requests and continue to serve genuine Requests?
2) Regarding the Certificate Revocation framework, is there an existing
methodology to know if the producer has been compromised?
3) I was also hoping for a few resources on How the FIB is populated.
Thanking you in advance and hoping for your guidance.
Yours sincerely,
~Shashank G
On Mon, Dec 25, 2023 at 10:56 PM Lixia Zhang <lixia at cs.ucla.edu> wrote:
> "CertRevoke: A Certificate Revocation Framework for Named Data
> NetworkingShashank, thanks for exploring NDN! From your questions, I guess
> you may be looking into NDN's name-based access control (NAC) solutions?
>
> Your first question: the concern seems that, given the data decryption key
> is encrypted in an object X using a legit's user Y's public key, an
> attacker Z could easily fetch the decryption key. As Kundan explained, Z
> can get a copy of X, but wont be able to read the decryption key in it,
> because Z doesn't have Y's private key.
>
> Your 2nd question: a good question, yes it is possible to compromise a
> producer and its key needs to be revoked. NDN based systems try to minimize
> the danger and damage of key/cert compromises by shortening their life
> times, though compromises detection is still needed.
> for revocation, there's initial work on NDN cert revocation: "CertRevoke:
> A Certificate Revocation Framework for Named Data Networking",
> https://dl.acm.org/doi/pdf/10.1145/3517212.3558079, which utilizes
> distributed ledgers. The paper referenced DLedger from several years ago, a
> more recent work is
> "CLedger: A Secure Distributed Certificate Ledger via Named Data"
> https://ieeexplore.ieee.org/document/10279244
> again this is very initial work, we are extending it in another ongoing
> project to cover more general cases.
>
> Lixia
>
> > On Dec 24, 2023, at 11:02 PM, Shashank G via Ndn-interest <
> ndn-interest at lists.cs.ucla.edu> wrote:
> >
> > Hi all,
> >
> > I am Shashank, a sophomore at National Institute of Technology,
> Karnataka from India. I recently began exploring NDN and have been
> fascinated by its data security aspect. However, since I am new to the
> field, I have quite a few doubts regarding the same, and I was hoping for
> your patience and guidance to clarify them.
> >
> > 1) I was trying to understand how cryptographically signing packets
> works, and have got a certain grasp of it's advantages, however, I had a
> doubt - If the public keys themselves are named, then with the right naming
> convention, couldn't an attacker get access to data that he is not supposed
> to view. How is this prevented?
> >
> > 2) Is there any mechanism to detect if the producer of data has been
> compromised, i.e, his private key has been obtained by a third party? If
> so, since the certificates are cached, how do we detect if the producer is
> safe or not?
> >
> > I look forward to learning a lot here and eagerly await your response.
> Thank you.
> >
> > Yours sincerely,
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu
> > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20231229/2fc01947/attachment.html>
More information about the Ndn-interest
mailing list