<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with attestation]]></title><description><![CDATA[A list of topics that have been tagged with attestation]]></description><link>https://board.circlewithadot.net/tags/attestation</link><generator>RSS for Node</generator><lastBuildDate>Thu, 30 Apr 2026 23:33:53 GMT</lastBuildDate><atom:link href="https://board.circlewithadot.net/tags/attestation.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[I am reading more about Free &#x2F; open source alternatives to Google&#x27;s Play Integrity tooling, sometimes called &quot;attestation&quot;.]]></title><description><![CDATA[@MWelchUK @neil The problem is, you don't have to find an exploit on a properly updated device, you have to find an exploit on a device that you control, with an OS version that provides PCR values that the remote attestation thing trusts in building its chain of trust.  That's a much easier problem, because you can usually use publicly disclosed vulnerabilities, often ones with PoCs attached to the disclosure.Linux averages one CVE per 1.5 days.  How hard do you think it is to find a local privilege elevation that can compromise an Android kernel or part of the attestation infrastructure?]]></description><link>https://board.circlewithadot.net/topic/42111a10-49f0-4751-b525-dfb399357b50/i-am-reading-more-about-free-open-source-alternatives-to-google-s-play-integrity-tooling-sometimes-called-attestation-.</link><guid isPermaLink="true">https://board.circlewithadot.net/topic/42111a10-49f0-4751-b525-dfb399357b50/i-am-reading-more-about-free-open-source-alternatives-to-google-s-play-integrity-tooling-sometimes-called-attestation-.</guid><dc:creator><![CDATA[david_chisnall@infosec.exchange]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>