Announcements
- Oh, bother! No topics were found here.
Chris Torr
Forum Replies Created
-
AuthorPosts
-
Chris TorrKeymasterAugust 7, 2020
Hi, sounds like you need to register htermlib.dll found in the SmartDeck bin directory using regsvr32.
Chris TorrKeymasterAugust 7, 2020KeyCorp became Multos International (same implementer id) so your chips will do the memory defragmentation.
Chris TorrKeymasterAugust 7, 2020Hi thanks for the question.
Memory defragmentation is technically optional in the MULTOS specifications.
However I know for sure that Multos International implementations do memory defragmentation as part of application deletion and think that Samsung implementations do the same. I’m not sure about the other implementers but could find out. Who is the implementer of the chips you are using?
You can find out by sending the GET MULTOS DATA APDU – the implementer ID is the 4th byte. The latest MUtil can send this command for you and interpret the result.
Thanks.
Chris TorrKeymasterAugust 7, 2020Just a note to say that macros for these “additional static” primitives will be included in the next version of the C-API (multos.h) currently under development.
A future version of SmartDeck will include features to automate the creation of additional static space.
Regards,
Chris.Chris TorrKeymasterAugust 7, 2020Hi Tom,
The Memory Copy Additional Static primitive (along with the other additional Static primitives Memory Fill Additional Static and Get Static Size) allows applications to access Static data that is outside of the normal data address space that is only accessible by the MEL instructions and all the other primitives.
The normal address space that applications have access to has a size of 64K as MULTOS has a 16-bit segment addresses. This 64K address space holds the application’s Static and Dynamic areas together with Public (the IO buffer). Static always starts at segment address 0 and the maximum size of Static that is accessible through this address space is implementation-specific. For Multos International implementations this is 32K as Public starts at 0x8000. In this case if an application is loaded with a Static size of greater than 32K then the Static data that is beyond the first 32K is only accessible using the Memory Copy Additional Static and Memory Fill Additional Static primitives, and these primitives use an offset from the start of Static (i.e. the start of Static that is at segment address 0). Note that these primitives also have access to the lower area of Static that’s in the normal address space but normally applications would access this Static area using the standard MEL instructions and primitives.
The Get Static Size primitive returns the total size of Static including the area that is outside of the normal address space.
Typically applications would be implemented such that all its fixed-size Static variables are located at the start of Static, being defined in SmartDeck as normal Static variables. The variable-size data elements (such as a biometric data in the case of ePassports and identity cards) would then be located above this fixed-size data and depending upon the size of this data some or all of the variable-size data elements would only be accessible by the Memory Copy Additional Static and Memory Fill Additional Static primitives. When the application is built the Static size held in the ALU will be the size of the application’s fixed-size Static variables. When the application is loaded the ALC would be created that specifies the total size of the application’s Static – i.e. the size of the fixed-size variables together with the variable-size data elements. For example, if an application has 10K of fixed-size variables and it is required to store 30K of biometric data then the ALC would have a Static size of 40K.
Regards,
Tony Jeffreys
Multos InternationalFebruary 21, 2013 at 9:02 am in reply to: AES key length in blockencipher and blockdecipher primitive #295Chris TorrKeymasterAugust 7, 2020Hi Alex,
I’ve checked out the MULTOS specifications and yes, you can use 24 and 32 byte AES keys with the block encipher / decipher primitives if the implementation supports those lengths.
I’ll update this in the next release of the MDRM. Thanks for pointing this out.
Chris. -
AuthorPosts