<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MICSTATUS is not set to 1 when decrypting packet</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/19726/micstatus-is-not-set-to-1-when-decrypting-packet</link><description>Hello Nordic team, 
 I am developing a proprietary radio protocol and i am using aes ccm peripheral for encryption (i am a begginer). The packets seem to be correctly encrypted ( the error event is not trigged while the endskgen and endcrypt event are</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 17 Apr 2018 11:31:50 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/19726/micstatus-is-not-set-to-1-when-decrypting-packet" /><item><title>RE: MICSTATUS is not set to 1 when decrypting packet</title><link>https://devzone.nordicsemi.com/thread/128622?ContentTypeID=1</link><pubDate>Tue, 17 Apr 2018 11:31:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:33f13c68-b06d-403e-a581-8530063596b5</guid><dc:creator>Harald_F</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;i had the same problem.&lt;/p&gt;
&lt;p&gt;A failed MIC Check after&amp;nbsp;decryption of radio packets&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;I&amp;nbsp;tried to encrypt packets on the fly at the transmitter.&lt;/p&gt;
&lt;p&gt;So NRF_CCM-&amp;gt;INPTR and NRF_CCM-&amp;gt;OUTPTR both pointed to the same array-address as&amp;nbsp;&lt;span style="font-family:inherit;"&gt;RADIO-&amp;gt;PACKETPTR.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;&lt;/span&gt;&lt;span style="font-family:inherit;"&gt;At the receiver side i had the problem, that the decrypted data was ok, but the MICSTATUS was still zero.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;Following step solved the issue:&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;I&amp;nbsp;removed the inplace operation,&amp;nbsp;by letting NRF_CCM-&amp;gt;INPTR and&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;span&gt;NRF_CCM-&amp;gt;&lt;/span&gt;OUTPTR point to different arrays.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;The calculated MIC was different... and&amp;nbsp;the MIC check at the receiver passed.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style="font-family:inherit;"&gt;&amp;nbsp;&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: MICSTATUS is not set to 1 when decrypting packet</title><link>https://devzone.nordicsemi.com/thread/76755?ContentTypeID=1</link><pubDate>Mon, 20 Feb 2017 18:18:11 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ff0807ab-a9c5-4062-92e0-a5d78ad61469</guid><dc:creator>Kevin</dc:creator><description>&lt;p&gt;Nordic Team informed me that the space reserved for area pointed by scratchpointer must be the size of the maximum packet size the length field can permit + 16 bytes. For example if you work with a 8 bit length field, the space reserved for scratch pointer area must be 255 + 16 bytes. you can heve more details here : &lt;a href="https://devzone.nordicsemi.com/question/75243/what-is-actual-size-required-for-scratch-area-for-ccm-on-nrf52/"&gt;devzone.nordicsemi.com/.../&lt;/a&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: MICSTATUS is not set to 1 when decrypting packet</title><link>https://devzone.nordicsemi.com/thread/76754?ContentTypeID=1</link><pubDate>Thu, 16 Feb 2017 10:16:39 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ce843a95-b00b-42f4-83ce-31bbfa667a46</guid><dc:creator>Kevin</dc:creator><description>&lt;p&gt;OK i found the problem: the buffer pointed by scratch pointer was placed in memory just before the buffer pointed by cnfpointer. So the data pointed by cnfpointer was overwritten by ccm peripheral! In my case data is written on 267 bytes after the scratchpointer start address (value stored in SCRATCHPTR register of CCM peripheral) . So if you use ccm peripheral and have the same problem you should try to reserve a big memory area for scratchpointer (&amp;gt;300 bytes).
Ps : thanks you for your answer Roger!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: MICSTATUS is not set to 1 when decrypting packet</title><link>https://devzone.nordicsemi.com/thread/76753?ContentTypeID=1</link><pubDate>Thu, 16 Feb 2017 08:48:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:c5c14f00-c99c-4021-a4e8-bc65a0b4ac51</guid><dc:creator>Kevin</dc:creator><description>&lt;p&gt;Yes i try to do the same thing on the same device (encryption+decryption without transmitting packet) and the buffer content at the output of the encryption is the same than the buffer at decryption input. The decryption gives the good result but the mic check fails every time.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: MICSTATUS is not set to 1 when decrypting packet</title><link>https://devzone.nordicsemi.com/thread/76752?ContentTypeID=1</link><pubDate>Thu, 16 Feb 2017 02:18:21 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4300c91c-edaa-4d7b-ba6a-20d1dc9ca571</guid><dc:creator>Roger Clark</dc:creator><description>&lt;p&gt;Did you try writing a test application which just encrypts to a buffer and the decrypts the same buffer (no transmission etc) ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>