Point 2 (ciphering state): this one’s hard. There is no standard command to retrieve the ciphering state from the MODEM. Some chipsets have non-standard additions which allow you to query it, and some others might provide it as an unsolicited message over the UART control interface.
Furthermore, there’s a little status flag in your SIM card set by your network which is literally an over-ride to prevent the user from knowing the ciphering state. I don’t know whether this is implemented by the phone OS (so it’s of no consequence to us) or the modem (which will either lie when asked or stop sending unsolicited messages about state changes). It might well be the latter - the Intel XMM7260 has a command, “AT+XUCCI”, for which the strings output of the modem firmware seems to indicate that it tells the ciphering indicator, but all I get is “ERROR” in response. The SIM card might have this flag set, I don’t know.
I did read somewhere that one can obtain some information about the current ciphering parameters by querying values from the SIM card (such access is from an AT command in the 3GPP/ETSI standards), however I don’t recall exactly where I read this, so don’t rely on it.
The most reliable method, of course, is a raw packet dump of the encryption negotiation sequence, but that’s annoyingly hard (see later).
Point 3 (cell tower information): this is available via a standard AT command, AT+CREG, and if this particular state changes, the MODEM should say so via readable ASCII text through its serial port interface. See ETSI TS 127 007 (most recent version is here, or you can just search for it on http://www.etsi.org/standards-search) or 3GPP TS 27.007 (they’re the same thing with different names) for more details.
Point 4 (monitor mode on cellular network) and point 6 (notification of silent SMS) are basically the same thing - a raw packet dump of everything over the air interface. This is annoyingly hard to obtain. The means for obtaining it from Qualcomm chips is known (see the SnoopSnitch project) and, rather nicely, both the required commands (some binary magic sniffed from the USB port when using a QC diagnostic tool) and the output format have remained standard across multiple generations of QC chips.
Infineon/Intel modems can theoretically output raw packet traces (see Darshak for the Samsung Galaxy S3, or XGoldmon for various older Samsung phones), but while the commands to get it to emit said raw packet traces appear to be similar, the output format varies between generations and it doesn’t seem to work on later devices. I’ve been trying to get this information out of an Asus Zenfone 2 (Intel XMM7260 modem), but I haven’t had any luck in finding any recognisable packets from the data dump and my “technique” is little more than blindly throwing AT commands at it then throwing the dump into a hex editor.
I don’t know enough about Samsung, Mediatek, HiSilicon or Icera (can you even get their standalone modems any more?) chipsets to say any more on that front.
Point 7 (per-application access controls): this looks like a good use of SELinux, AppArmor or something of similar ilk. The real difficulty lies in configuring said access control software, but it’s essentially something which we can in theory control regardless of the particular hardware choices.
Point 11 (multiple satellite navigation constellations): this is almost guaranteed, it’s actually very hard to find chips nowadays which only support one single constellation. If they go with a U-Blox (as tentatively suggested here) module, then we do indeed get all 4.
Point 12 (replaceable battery): that’s part of the specs. Capacity… well, that depends on what you do with it, I suppose (it also helps that we won’t be running the overhead of an enormous Java stack like Android does). At the very least, you’ll easily be able to flip the case open and put in another battery if your main one runs low.
