Encrypt than MAC scheme for Home Security system Developing a wireless home security system based on STM32M0 µcontroller, I'm currently looking for the best way to manage encryption/authentication.
For information, the STM32M0 has an AES hardware acceleration module with main modes.  

So , I looked first for AES-GCM as AEAD, but there's too much overhead: my data is about 16 bytes , maybe 4 of additional data, and there's 12 bytes IV, and 16 bytes Tag.
I want to avoid that IV / Nonce to reduce frame size.  

So here's the intended scheme:  


Encrypt plaintext (that contains a UNIQUE 32bits counter for frames) using AES.   
Append additional data without encrypt it 
Use a MAC without IV/nonce (like CHASKEY, optimized for embedded)


This way I have to use 2 keys , one for AES and one for the MAC. I guess the second can be derivated from the first.

Is this scheme is secure enough for the purpose ?
my data is about 16 bytes , maybe 4 of additional data, and there's
  12 bytes IV, and 16 bytes Tag. I want to avoid that IV / Nonce to
  reduce frame size.





  Encrypt plaintext (that contains a UNIQUE 32bits counter for frames)
  using AES.


So this means that you already have a 32-bit unique value per-message. If you can guarantee it to be unique across all messages under any specific key, then you can use these 32 unique bits, padded with 0s to 96 bits as your IV for AES-GCM. Or you can construct the IV as your 32-bit unique value + 64 bit of randomness per message, which is transferred explicitely.

If you want to optimize even further (at the cost of security, mind you!), you could use a mode that allows tag truncation (do not truncate AES-GCM tags!), such as AES-CCM. There you would use a similar IV setup as above and additionally you could truncate a few bytes of the authentication tag. The calculation is simple: Let $r$ be the maximal risk you are willing to take that a forged message slips through. Let $e$ be the maximal number of times you output "invalid" for a given key on invalid ciphertexts. Then your tag should have length $l$ at least $l\geq \log_2(e/r)$ (this does not apply to AES-GCM). For more information, have a look at appendix B of NIST SP800-38C (PDF).